Well, I'd put the time based releases aside for a while with the
following comment on that and stick to the original topic of this
discussion.
In order to be able to produce real time based releases our release
process and it's infrastructure have to be improved. Right now the
process consists of ~30 steps out of which ~15 require changes on the
actual code to be released. These includes:
* New Splash Screens (As you see on the list I'm trying to work on
this as well now)
* New versions to display in several places
* Bumping the versions of the modules on two branches
* API Signature sealing
We need to automate these things first (or talk about, if we could skip
some of the steps), then we shall be able to discuss time based releases.
In theory we shall reach a point when we have a build job in Jenkins
that input is a git revision and a release version (like 12.0) and it
would create, a branch with a source and binaries with the correct
version numbers, branding, etc. and also bump versions on the source branch.
I'd probably itemize the tasks what should be done for this in JIRA and
create a WIKI page for that as well.
I would just concentrate on releasing a patch with the least but
sufficient effort right now.
On 4/28/19 1:20 AM, Neil C Smith wrote:
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
