+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

+1 On Fri, Nov 12, 2010 at 8:02 AM, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 11/12/2010 08: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.

+1. -- Sergiu Dumitriu http://purl.org/net/sergiu/

+1 On Fri, Nov 12, 2010 at 08:02, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne