[OpenLayers-Dev] maintenance releases

Tim Schaub tschaub at opengeo.org
Wed Sep 16 16:39:32 EDT 2009


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 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.

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.

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.

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.

Tim

> But I fully agree with releasing more often. So why not just doing
> minor releases every 3-4 months, no matter what, and simplifying the
> release process (no release cycles)? Before kicking a release a "2
> weeks from the next release" email could be sent, this would be for
> people to work on patches and reviews.
> 
> Thoughts?
> 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.



More information about the Dev mailing list