[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