Hello wizards,
I'd like to understand your workflow and practices for developing new tools and updating them.

Additionally, I need advice in these areas where I struggle:

VERSIONING:

1. Why does Houdini's built-in HDA creation tool force versioning to start at 1.0, not 0.1? I believe "1.0" should represent the first milestone, not the starting point for a new tool.
   
2. The built-in tool doesn't allow granular versioning like 1.0.3, leading to a premature 2.0 milestone. It increases by 0.1 with each save, permitting only 10 saves before a new x.0 milestone. Established HDA libraries (e.g., MOPs) use the x.x convention, so I wonder how they handle more granular saves during development.
   

A solution for my needs might be manual versioning or a custom HDA saving tool, like this one?
https://www.youtube.com/watch?v=pLM0LESO_kA [www.youtube.com]


EMBED INTERNAL ASSETS:
How do you handle the updating of a HDA that uses internal assets?
My HDAs often use internal service HDAs (not available to users in the TAB menu).
I use the "embed internal assets" function, but when saving the main HDA to a new version, the instances of sub-HDAs used in the MAIN HDA network are replaced with a "Merge Sop" node, which breaks the whole network.
This could be due to the main HDA's different namespace in the new version. When I use the embed function, the new installed internal asset has adn::Sop/Main_HDA::1.0::adn::Sop/Internal_HDA::1.0, so it's only available to Main_HDA::1.0.
Then when updating the Main_HDA to a new version, the internal_HDA isn't available to adn::Sop/Main_HDA::1.1, even if installed in the same library file, and thus the instances inside the network of main_HDA::1.1 are automatically replaced with a Merge Sop node.

It is such a struggle every time I save to a new version, because I have to manually update every instance of any internal hda used in the network. I believe I'm not using a the correct workflow here.


GITHUB REPOSITORY:
I'm new to GitHub and like the idea of an online public repository for my HDAs.
What's your workflow with GitHub used for Houdini development.


ROADMAP, FEATURE LIST, TASKS, TODOs, REQUESTS, CHANGELOG:
What's your approach to these aspects? Do you use any service? I'm interested in tracking my HDAs, organizing them in a database, maybe using Notion. It might be overkill or time-consuming for a solo dev like I am, so I'm open to learning from your experience.

OK, I recently discussed with Chat-GPT and devised a GitHub workflow for developing and publishing a collection of HDAs.
Key points include:

• Adopting major-minor versioning for HDAs, like 1.4, nothing more granular.
  
• Hotfixes and maintenance updates won't change minor version numbers. Users should refer to the repository release changelog
  

to identify hotfixed versions.
Any feedback or suggestions for this new-to-GitHub approach are appreciated.

Managing Houdini HDAs Repository: Guidelines for Development and Hotfixes

1. Public Main Branch: This branch contains the stable versions of HDAs, with versioning in the format x.x.

2. Hidden Develop Branch: This branch is where new minor versions of HDAs are developed. Add the suffix -dev to the HDA file names while working on them in this branch.
Example: If the stable release for a particular HDA is 1.0, the development version would be named my_hda.1.1-dev.

3. Development and Merging Process:
a. Develop new minor versions of HDAs in the hidden develop branch.
b. Once a milestone for the new minor version is reached, rename the HDA file to remove the -dev suffix and update the minor version number.
Example: Rename my_hda.1.1-dev to my_hda.1.1.
c. Merge the updated HDA file into the main branch using the git checkout method. This ensures that only the specific HDA file is merged, without affecting other files in the main branch.

4. Hotfixes for Current Minor Versions:
a. For maintenance updates or hotfixes, create a new branch from the main branch, with a descriptive name like hotfix/hda_name.
b. Apply the hotfix or maintenance update to the specific HDA in the new branch.
c. Test the changes to ensure they work as expected and do not introduce new issues.
d. Commit the changes in the hotfix branch with a descriptive commit message, such as "Hotfix for HDA_name: description of the fix".
e. Switch back to the main branch and merge the hotfix branch into it.
f. Push the updated main branch to the remote repository and delete the local hotfix branch.

5. Repository Releases, Hotfixes, and Versioning: When ready to release a new version of the entire HDA collection, create a new repository release that includes the updated HDAs and any hotfixes applied to them. Note that a hotfixed HDA may maintain the same version number, and it is important to refer to the repository release version to understand which specific hotfixes have been applied.