Different approaches are used for updating extension index. One is to specify git hashes, another is to define a branch name. We started an interesting discussion around a pull request. I copy it here so that the discussion can be joined by more developers.
Manual updates of git hashes takes time and error-prone. You can make copy-paste errors, update the wrong s4ext file or the wrong branch of the ExtensionIndex, etc. It should be avoided.
If for some reason you feel safer with having specific git hashes in the s4ext file then the update should be fully automatic. You can use @jcfr’s extension wizard scripts.
However, a much cleaner and better controllable workflow is to use protected release branches and set the release branch name in the s4ext file instead of a specific hash. The release branch can be master or any other name. Protected branches can be configured to require reviews and be writeable only by certain users. Therefore, instead of enforcing Slicer core developers to click blindly on merging a new git hash, you can control what gets into the release in your own repository by defining your own rules that you set for the protected branch.
The protected branch is nice, simple, and almost zero-effort, so I think that would be great to encourage for all extensions where people don’t want to build off master in the short-term.
Another potential approach is a release bot. There are a few around, but the one I’m most familiar with is “attobot” for Julia packages. It is a travis hook that runs on AWS Lambda; essentially watches any release-tags on a repository, and automatically makes a validated PR to the central index when a new release is created. Automated update was imperative for Julia with close to 2000 packages, because full manual review of every update PR by only 3-4 people was starting to be a big time-sink and blocker. It’s not so much an issue for ~100 extensions, but clean, validated automation is always nice in any case. The code is quite short and MIT licensed, so it wouldn’t be too crazy to just adapt it (if/when we have full continuous integration for extensions).