Hi, +1 as well.
Guillaume On Fri, Nov 12, 2010 at 10:45, Marius Dumitru Florea < [email protected]> wrote: > +1 > > Thanks, > Marius > > On 11/12/2010 09:02 AM, Vincent Massol wrote: > > Hi committers, > > > > I've started a thread recently on this list about the Roadmap leading to > the 3.0 release. The outcome of this thread is that we need a global > strategy for our major releases (e.g. the "2" in the "2.N" releases). > > > > First here's the rationale for doing major releases: > > * It's a way to mark progress to the outside world and to be able to do > open source marketing > > * It's a milestone in the project's life and it feels good to do it. It > makes us developers feel proud of our achievements too. > > * It allows us to move forward since it's a good time to think back about > what the xwiki project is and where it wants to go > > > > I've tried to capture all arguments from the past discussion to come up > with a Release Cycle strategy that take them into account without changing > our core values which is to do timeboxing (rather than featuritis). > > > > So here goes the proposal: > > > > 1) Introduce the notion of "Release Cycle". > > - A release cycle means all the release of the type X.N where X is the > major and represent the cycle (and N is a non constrained number 0<= N< > infinity) > > - Duration: 6 minor releases (e.g. 2.0 till 2.5). That's approximatively > 1 year since each minor release is about 2.5 months.<fun>For the geeks in > us, six is a unitary perfect number, a harmonic divisor number and a highly > composite number (see http://en.wikipedia.org/wiki/6_(number)).</fun> > > > > 2) When we release the last minor of the cycle we announce it: > > - Send mail mentioning that the cycle is over and that version X.N is the > last minor release of that cycle (but there can still be bugfix releases: > X.N.P) > > - In that mail, explain all the major features that were implemented > during that release cycle (make a special Release Notes for a Cycle) > > > > Advantages: > > * Users are satisfied since it means X.0 is the first release of a cycle > (this was one of the major comment in our past discussion thread) > > * For developers, we have a notion of "work done", ie when a cycle is > over. > > * We have 2 points of communication: > > ** When a cycle is finished (with the last minor release of the cycle) > > ** When a new cycle begins (to describe the rough directions of the new > cycle and internally to decide where the project is heading) > > > > Note: The rule about 6 minor releases is really important for several > reasons: > > * It implements timeboxing our core tenet regarding releases > > * It allows us to not have to rediscuss when is the major going to happen > every time > > * It allows us to know well in advance when the major release is going to > happen and thus to adjust our commits during the whole cycle > > * It prevents featuritis > > > > Note 2: Having rule doesn't mean we'll never have good reasons to do > things differently. It may happen that from time to time we need one more > release for a cycle for example but this will be treated as an exception and > will need to be justified. What's important is to have defined rules in > order to give a stable rythm to the dev process. > > > > Here's my +1. > > > > Thanks > > -Vincent > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
