12 Nov
2010
12 Nov
'10
12:09 p.m.
+1
Denis
On Fri, Nov 12, 2010 at 11:35, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
Hi,
+1 as well.
Guillaume
On Fri, Nov 12, 2010 at 10:45, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
+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).
about
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 what the xwiki project is and where it wants to
go
changing
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 our core values which is to do timeboxing (rather
than featuritis).
approximatively
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 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)
cycle
- 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 (this was one of the major comment in our past
discussion thread)
happen
* 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 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
and
* 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 will need to be justified. What's important
is to have defined rules in
order to give a stable rythm to the dev process.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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