+1
On Fri, Nov 12, 2010 at 08:02, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs