On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, <mblaes...@doppel-helix.eu> wrote:
> > at some point in the past we said, that we wanted to do time based > releases and I would still follow that thinking. > > I would branch any release of master, as late as possible, (not some > random other base), do testing and only minimal cherry-picking, > release. Repeat X months later. > > That way we know: > > - when a release is due > - what will be in the release (the state of master) > +1 to this. At some point in the initial thread on time-based releases Jan also suggested merge windows for master to keep cherry picking minimal. I think being stricter about what gets merged to master and when might be required? I was looking around the NB11 release process a while ago, and wondered about feasibility of making some of those release branch commits be configurable in the master build instead? That way branching could happen more easily later in the schedule, after testing for final beta maybe? Still think next should be NB 12.0 to do time-based releasing properly! As Matthias said, you don't know for sure what's in it until you freeze master, so how do you know it's major or minor? 11.1, 12.1 etc. could be reserved for patch updates where a new full binary download might be warranted? There using release branch possibly makes more sense. Best wishes, Neil >
