As 3.9 approaches, I think it's time to take a look at what our release
and packaging process is. It seems that some of the packaging details
have been forgotten in the natural course of people joining and retiring
from the project. Let's make an effort to document the process ahead of
time so we know exactly what we're doing going into the next release.
I'd welcome any contributions, but I also have some specific questions:
- How do we package binaries for Linux? (3.7 and 3.8 didn't have them.)
- Most Linux repositories have fallen behind. How do we update them?
- GitHub's source code packaging doesn't include submodules. How should
we deal with that?
- merging the release branch into master turned out to be problematic. These can be large merges where git often enough makes choices that turn out to be wrong. High risk of introducing regressions. And it is also not trivial to keep release branch specific commits out of this merge. The principle that fits sc better: move commits from master to release branch by cherry picking. Release branch specific fixes should of course go into the release branch only
- committing to the release branch is reserved to the release manager (as an agreement, no buttons required). This makes sure that s/he doesn't loose the overview. S/he also has the last word in controversial cases.
Another crucial point is to split off the release branch as late as possible. Here pessimism rather than optimism is the right attitude. Beta-phases should be as short as possible, not more than a month, and there should not be more than one or two, otherwise attention between master and release branch will be divided too long. In effect the release branch should only be split off once we think we are ready for release. Then feedback from public exposure of the beta will hopefully produce a few error-reports that can be fixed before the actual release.
You say that master is unstable, but I don't see that SC has the woman-power to keep an unstable and stable branch yet. Master always needs to remain as stable as we manage to, features that could reduce functionality/stability need to remain in separate development branches until they can be considered "stable" or complete. The reason for this is that we have too often in the past been hit by provisional contributions to master that then were never - or only with an intolerable delay - fixed by the original contributor. The responsibility for the stability of new contributions lies strictly with the original contributor. Also, as has been the case for years and without there being a sign that this might change in the closer future: the actual use of the master branch is the only real world testing new contributions get before a release. If master cannot be used, this crucial testing will fall away. Therefore it is also not good if large commits are done shortly before a release.
sc-dev mailing list