Hi, Thanks for moving this discussion forward. I do think we need much more regular releases.
> - devel as the branch for developments, master for releases and > security/bug fixes Changing the branching model is very difficult to do. I think it is better to ignore branches for now and focus on coming to an agreement about more frequent releases, lest this discussion, too, ends up reiterating "stable" branches and the finer points of release maintenance. > - major should follow core merges to devel > - minor should follow non-core teams merges I think this is a good idea to start with. Releases are made a short time after the core team branch is merged. This would give us a new release whenever e.g. the default GCC and glibc is bumped up. We could aim for a release two months after the merge to allow for minor fixes after the merge. I'm not sure if these merges should justify a new *major* release, but I think it is good to have a new release then. Not all team branch merges may justify a new release. The r-team branch, for example, usually contains just a couple hundred patch-level package upgrades that are restricted to packages from CRAN and Bioconductor. It is only sometimes that the R version is increased or the Bioconductor release version is changed --- only in those cases I would consider it appropriate to bump up the Guix minor (or patch-level) version number. -- Ricardo