12 Nov
2010
12 Nov
'10
12:56 p.m.
+1
Thanks,
Caty
On Fri, Nov 12, 2010 at 13:09, Denis Gervalle <dgl(a)softec.lu> wrote:
+1
Denis
On Fri, Nov 12, 2010 at 11:35, Guillaume Lerouge <guillaume(a)xwiki.com
up
the
in
.</fun>
releases:
cycle)
going
wrote:
Hi,
+1 as well.
Guillaume
On Fri, Nov 12, 2010 at 10:45, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
do
+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 > 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 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 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 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_…
>
> 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 X.N.P)
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 - 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 > > ** When a new cycle begins (to describe
the rough directions of the
new
cycle and
internally to decide where the project is heading)
happen
> every time
> > * It allows us to know well in advance when the major release is
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 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