+1 A
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
