+1 Thanks, Caty
On Fri, Nov 12, 2010 at 13:09, Denis Gervalle <[email protected]> wrote: > +1 > > Denis > > On Fri, Nov 12, 2010 at 11:35, Guillaume Lerouge <[email protected] > >wrote: > > > 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))<http://en.wikipedia.org/wiki/6_%28number%29%29> > .</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
