[Mailman-Developers] Next Postorius release

[Barry Warsaw]

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