Andr

Ah, now I see what you mean.
Yes I experience the same issue of 404.

Might be worth to fill a bug report with the Support

I actually prefer sidefx.com as the local help tends to be slower than the remote help - quite the laugh, right? Besides, on my machine, the local help has a habit of triggering session crashes.

Slightly ot:
I've noticed that few companies have now integrated chatbots that are specifically fine-tuned for their services. Unlike the first generation of chatbots, which merely redirected users to specific pages of documentation or FAQs, these modern chatbots provide meaningful responses based on user inquiries.
Can you imagine how useful a well-integrated, fine-tuned chatbot could be for newcomers to Houdini? I'm pretty sure this could significantly increase Houdini's adoption among a larger user base

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.