Some of this I believe is already leveraged but just restating in current conversation as applicable.
Seem to recall the “temple” Jira ticket with all the steps define for a release previously. https://issues.apache.org/jira/browse/NETBEANS-2052 (https://issues.apache.org/jira/browse/NETBEANS-2052?jql=text%20~%20%2211.0%22) is created. Maybe when a release is initially planned, it needs to be cloned (adding any new sub tasks as changes) and assigned to release manage. As candidates tickets for inclusion are identified they are linked in the release ticket, marked in the candidate ticket, inclusion of applicable pull requests where applicable. For patch releases, assume similar clone be created but maybe with a subset of the tasks to reduce work for the full release. What kind of tasks do you think are fully needed in a patch release? Are there any ways to link a JIRA task with a build requests in some way so that when one or the other is triggered (maybe some state change) it would start a give build to automate some of the tasks? Assume at a minimum some build types may need monitoring to ensure good build quality to an acceptable level. Maybe an extra subtask of “running unit test suite x” with passing at a minimum? Eric Bresie ebre...@gmail.com > On April 28, 2019 at 8:47:20 AM CDT, Laszlo Kishalmi > <laszlo.kisha...@gmail.com> wrote: > 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 > >
