On Jun 30, 2017, at 02:21 PM, Simon Hanna wrote:

I know it might be a little early, but I'd like to talk about the plan for Postorius (Mailman in general) releases moving forward.

Should there be more point releases? 3.1.X? Or just 3.X? Are releases bound to Core releases (following core's release numbering?)? How often do we do releases?

Every X merge requests and/or X months?

I'd like to know that just to organize issues/merge requests and so the whole process can be planned a little more...

Would be also helpful to create this information in Gitlab milestones...

Hi Simon, thanks for bringing this up. It's not at all too early to discuss this, and it's something I've struggled a bit with as well.

TBH, part of my problem with this is tooling. I think both git and gitlab aren't as amenable to long-term maintenance release administration as say bzr and Launchpad. Sure, we can create git branches for maintenance releases, but I don't think the cherry picking workflow is nearly as well documented or consistently applied across projects as with bzr. Worse, I really miss the notion of "bug tasks" in Launchpad, where a single bug can target mutiple maintenance releases, and each such target can be closed separately. Watching what happens in upstream Python for example; so much extra tooling had to be created to manage that, although they do have a worse problem because there are many more versions active at the same time. (FWIW, github isn't any better here.)

I did release Core 3.0.x maintenance release and intended to continue to do so, but 3.1 eventually diverged to much and it was simply infeasible given my available cycles. The branch still exists, but we'll never release off of it now so I've been thinking about tagging it and deleting the branch.

For Core 3.1, we do have a release-3.1 branch and I've started to label some bugs as 'backport candidate' for things I think could or should be backported from 3.2 (master). Cherry picking them is Work though, so we'll see if it happens. There may be more pressure to do maintenance releases as usage increases, and once we start seeing e.g. Debian packages and more update on Abhilash's docker images.

From a policy standpoint, I'd suggest the following:

• "Major" releases (second digit, much like Python) should be coordinated. I'd like to align our release on the same Major.Minor version numbers.

• Maintenance releases can be left up to the individual components. Do them if you can, and just rev the third digit as you see fit. We don't need to coordinate them, though it's critical that we remain even more vigilant against breaking any APIs in point releases. That's probably most incumbent on mailmanclient and Core.

• As to what to cherry pick, that's also up to the individual projects. As mentioned, in Core I'm tending to label things as "backport candidate", but still closing them when they are landed on master. I'm definitely open to suggestions here. I think we should be consistent across projects so it's easier to track.

• Yes, we should do point release milestones both in the individual projects and as a suite.

It still of course means we have to find the resources to do the cherry picks and releases. :(

Very much open to other thoughts and suggestions! -Barry