[OpenLayers-Dev] maintenance releases

[Christopher Schmidt]

On Wed, Sep 16, 2009 at 02:39:32PM -0600, Tim Schaub wrote:
> Hey-
> 
> Eric Lemoine wrote:
> > On Tue, Sep 15, 2009 at 9:00 PM, Tim Schaub <tschaub at opengeo.org> wrote:
> > It seems to me that what you'd like to see isn't really maintenance
> > releases. To me maintenance releases would be x.y.z releases with
> > fixes for bugs in x.y minor releases.
> > 
> 
> You're right, this wouldn't be patches applied to an x.y branch.  This 
> would be the trunk (or really it could be up to the release manager what 
> to release).
> 
> I was thinking more in line with what Andreas said (x.y is "extremely 
> stable" and x.y.z is the latest and greatest).

I do not like the idea of x.y.z releases being something other than a
release based on bringing back specific patches to a branch. I'd much
rather make our release process less onorous, and release a new version
every two weeks based on trunk or whatever you want to do, rather than
release trunk within the same branch. The idea that "2.8.0" would be
more stable than "2.8.3" is counter to all intuition I have regarding
version numbers, and I'd rather say "2.8 is a major milestone which
we've tested, 2.9, 2.10, 2.11 are minor, and 2.12 is another major
release" (Because we think it deserves the testing) than anything else. 



> I do think there is value in going through the full release process that 
> we have adopted.  However, the process is not compatible with a fixed 
> schedule.

What is the value? What do we gain? Honestly, we typically find a few
bugs to fix, but they typically affect a very small number of users, and
the number that we find before the release vs. the number we find after
the release really isn't that different anymore.

> I also don't want to commit to a fixed schedule (changing our process) 
> and then disappoint because nobody has any time to take the reigns.

If there is a no-RC release schedule, I will gladly take on a monthly
duty of either: 
 * backporting a set of patches decided upon by the community
   as neccesary to add to our 2.x.0 branch, and releasing a 2.x.0+1

 * releasing a new 2.y with the latest and greatest trunk.

If we were talking about more than monthly, I wouldn't want to do #1.

> So, I was hoping to settle on a second, less onerous process for more 
> frequent releases.  I'm not attached to the name, but I see value in 
> having some way to distinguish these from the regular x.y releases.

In Linux, I think this is/was done with the '.odd, .even' naming. I see
no reason that we couldn't do something similar with a wikipage listing
'stable' vs. 'cutting edge' releases.

> If we go this route, a release manager could choose: x.y or x.y.z (or 
> whatever).  If we don't change our x.y process (which I think has 
> value), x.y releases can't (strictly) be done on a schedule (the rc 
> cycle can be infinite).  If a release manager wants to stick to a 
> schedule, they pick the second process (maintenance, x.y.z, whatever). 
> The release manager could also choose the second process and not stick 
> to a schedule - but I would suggest making a process that at least makes 
> a schedule possible.

I don't disagree with this, but I think using x.y.z is not ideal because
it is against the grain of what is expected from a 'patch' release.

So, my argument would be to have a release manager decide of an RC-level
release is neccesary, and then just document which is which in our
'minor' versions wikipage.

(But I'm not dead-set against it, I Just find the possibility
counterintuitive.)

Regards,
-- 
Christopher Schmidt
MetaCarta