12 Nov
2010
12 Nov
'10
11:35 a.m.
Hi,
+1 as well.
Guillaume
On Fri, Nov 12, 2010 at 10:45, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs