Hey- Eric Lemoine wrote: > On Tue, Sep 15, 2009 at 9:00 PM, Tim Schaub <[email protected]> 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. _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
