Andras Lasso

Using `main` word in any other branch than the main branch could be confusing. I don't recall seeing such name. We could keep using the naming convention established by `v4.11`,...

Numpy uses `maintenance/1.2.x` (https://github.com/numpy/numpy). Jupyter (https://github.com/jupyter/notebook) just uses the `.x` suffix to differentiate branches from versions. Adding the `.x` could be nice, but maybe it is not worth switching to...

Don't forget to add all the readthedocs update steps you perform to the checklist to make it easier to create the next release. Note on readthedocs: Unfortunately, it [does not...

> We could have a mapping from maintenance/5.0 GitHub branch to v5.0 readthedocs version. I'm not sure if it's possible. Readthedocs users and developers have been discussing this since 2018....

I see, so the proposal is to name branches `maintenance/5.0` and tags `v5.0.2`. That would work. Documentation must be always done in the master branch. After someone makes the change...

According to @jcfr's proposal, the stable release documentation would not be updated automatically (because it would be based on a tag, not a branch). However, since user contributions to documentation...

> Since the time between stable releases is so long, it would make sense to backport relevant documentation updates to the stable. I really hope that from Slicer5 we can...

I see. I think it all depends on the frequency of stable releases. - Option A. Create a new stable release in every 3 months. We can essentially abandon stable...

I know that normally application settings is at the bottom of the Edit menu. That's why I tried to explain why not to follow this convention in Slicer. To summarize:...

I liked the consistency with other software but the experiencing the extra difficulty on using the menu (it takes at least 2x longer time to click on the last item...