Proposal about a time based release plan

[Jacopo Cappellato-4]

Hi all,

I would like to share some ideas I have to make our release plan more clearer, public and well defined.

This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful.
This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates.
For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this:

* release 11.04 around 2012-04-15
* release 11.04.01 around 2012-08-15
* release 11.04.02 around 2012-12-15

* release 10.04.01 around 2012-03-15
* release 10.04.02 around 2012-07-15
* release 10.04.03 around 2012-11-15

* release 09.04.02 around 2012-02-15
* release 09.04.03 around 2012-06-15
* release 09.04.04 around 2012-10-15

Or we could decide on a less aggressive schedule and release each branch every 6 months etc...

And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it).

In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases).

Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc...

When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread).
In the meantime, with this time based release plan we will have something real to play with.

Please let me know what you think.

Thanks,

Jacopo

[Adrian Crum-3]

Sounds great! I like the idea of separating release date roadmap from
release feature roadmap.

-Adrian

On 2/21/2012 9:18 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I would like to share some ideas I have to make our release plan more clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this:
>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>
> Or we could decide on a less aggressive schedule and release each branch every 6 months etc...
>
> And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it).
>
> In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases).
>
> Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc...
>
> When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread).
> In the meantime, with this time based release plan we will have something real to play with.
>
> Please let me know what you think.
>
> Thanks,
>
> Jacopo

[Jacques Le Roux]

Hi Jacopo,

Inline...

From: "Jacopo Cappellato" <[hidden email]>

> Hi all,
>
> I would like to share some ideas I have to make our release plan more clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I
> will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and
> announced in advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release
> from each branch every 4 months like this:
>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>
> Or we could decide on a less aggressive schedule and release each branch every 6 months etc...

6 months seems enough to me

> And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will
> not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to
> propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is
> closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen
> it).
>
> In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on
> this information could prepare in time for the upgrades (or switch between major releases).
>
> Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could
> skip a release if no changes since the previous one were committed etc...

+1

> When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not
> be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know
> it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement
> and effort... we can (and should) always try to do that also but this is another topic (for another thread).
> In the meantime, with this time based release plan we will have something real to play with.


I think these are neat ideas to start, thanks Jacopo

Jacques

> Please let me know what you think.
>
> Thanks,
>
> Jacopo
>

[Kiran-2]

I like the idea. Go for it!!

Regards,
Kiran Gawde

Senior Software Architect
Object Edge Inc
[phone] x108

"There are two kind of people: Those who do the work and those who take
the credit. Try to be in the first group because there is less competition
there."
"Never give up on what you really want to do. The person with big dreams
is more powerful than one with all the facts".




From:   Adrian Crum <[hidden email]>
To:     [hidden email]
Date:   02/21/2012 01:31 AM
Subject:        Re: Proposal about a time based release plan



Sounds great! I like the idea of separating release date roadmap from
release feature roadmap.

-Adrian

On 2/21/2012 9:18 AM, Jacopo Cappellato wrote:
> Hi all,
>
> I would like to share some ideas I have to make our release plan more
clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from
the due diligence when we will call for votes) because I will take care
about preparing release candidate files, sign them and call for votes;
then publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big)
difference that the release schedule will be decided and announced in
advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme
could be used for 2013 etc...) we will issue a release from each branch
every 4 months like this:

>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>
> Or we could decide on a less aggressive schedule and release each branch

every 6 months etc...
>
> And we could also vote in advance for the time a release branch will be
closed: for example we could vote that the community will not release and
apply patches to the release branch 09.04 after the release 09.04.04 (this
is just an example as I would like to propose to close the 09.04 branch
earlier than this). New patches/contributions (always welcome) for that
branch (after it is closed) will not be applied to the branch and will
stay in Jira for interested parties (unless the community will decide to
reopen it).
>
> In this way users will know in advance when a branch will be deprecated,
how many bug fix releases will be issued and based on this information
could prepare in time for the upgrades (or switch between major releases).
>
> Of course there will be exceptions: maybe we will have to release out of
schedule to fix some major security issues or we could skip a release if
no changes since the previous one were committed etc...
>
> When the plan is in place we could then prepare a nice roadmap diagram
to be published in our Download page. The roadmap will not be feature
based and for this reason it should be doable with the current structure
and resources we have in the community: I know it would be also nice to
plan and work together on a features set, but this will definitely require
more coordination, agreement and effort... we can (and should) always try
to do that also but this is another topic (for another thread).
> In the meantime, with this time based release plan we will have
something real to play with.
>
> Please let me know what you think.
>
> Thanks,
>
> Jacopo

[Erwan de FERRIERES]

Le 21/02/2012 10:18, Jacopo Cappellato a écrit :

> Hi all,
>
> I would like to share some ideas I have to make our release plan more clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this:
>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>

sounds good to me.

Regards,

--
Erwan de FERRIERES
www.nereide.biz

[Pierre Smits]

Hi All,

I am all for a roadmap. This will help us in communications with existing
and potential customers. It will also help us with planning of internal
activities related to the OFBiz product.

+1

Pierre Smits

2012/2/21 Jacopo Cappellato <[hidden email]>

> Hi all,
>
> I would like to share some ideas I have to make our release plan more
> clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from
> the due diligence when we will call for votes) because I will take care
> about preparing release candidate files, sign them and call for votes; then
> publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big)
> difference that the release schedule will be decided and announced in
> advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme
> could be used for 2013 etc...) we will issue a release from each branch
> every 4 months like this:
>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>
> Or we could decide on a less aggressive schedule and release each branch
> every 6 months etc...
>
> And we could also vote in advance for the time a release branch will be
> closed: for example we could vote that the community will not release and
> apply patches to the release branch 09.04 after the release 09.04.04 (this
> is just an example as I would like to propose to close the 09.04 branch
> earlier than this). New patches/contributions (always welcome) for that
> branch (after it is closed) will not be applied to the branch and will stay
> in Jira for interested parties (unless the community will decide to reopen
> it).
>
> In this way users will know in advance when a branch will be deprecated,
> how many bug fix releases will be issued and based on this information
> could prepare in time for the upgrades (or switch between major releases).
>
> Of course there will be exceptions: maybe we will have to release out of
> schedule to fix some major security issues or we could skip a release if no
> changes since the previous one were committed etc...
>
> When the plan is in place we could then prepare a nice roadmap diagram to
> be published in our Download page. The roadmap will not be feature based
> and for this reason it should be doable with the current structure and
> resources we have in the community: I know it would be also nice to plan
> and work together on a features set, but this will definitely require more
> coordination, agreement and effort... we can (and should) always try to do
> that also but this is another topic (for another thread).
> In the meantime, with this time based release plan we will have something
> real to play with.
>
> Please let me know what you think.
>
> Thanks,
>
> Jacopo
>

[Malin Nicolas]

it's a clear vision for end user :)

+1

Nicolas

Le 21/02/2012 10:18, Jacopo Cappellato a écrit :

> Hi all,
>
> I would like to share some ideas I have to make our release plan more clearer, public and well defined.
>
> This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful.
> This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates.
> For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this:
>
> * release 11.04 around 2012-04-15
> * release 11.04.01 around 2012-08-15
> * release 11.04.02 around 2012-12-15
>
> * release 10.04.01 around 2012-03-15
> * release 10.04.02 around 2012-07-15
> * release 10.04.03 around 2012-11-15
>
> * release 09.04.02 around 2012-02-15
> * release 09.04.03 around 2012-06-15
> * release 09.04.04 around 2012-10-15
>
> Or we could decide on a less aggressive schedule and release each branch every 6 months etc...
>
> And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it).
>
> In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases).
>
> Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc...
>
> When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread).
> In the meantime, with this time based release plan we will have something real to play with.
>
> Please let me know what you think.
>
> Thanks,
>
> Jacopo

[dhiraj.g]

Hi
It  is the good future plane and i like it.
+1


Thanks
 Dhiraj Gupta

[hongs bill]

That's very good.

+1

2012/2/23 Malin Nicolas <[hidden email]>

> it's a clear vision for end user :)
>
> +1
>
> Nicolas
>
>
> Le 21/02/2012 10:18, Jacopo Cappellato a écrit :
>
>> Hi all,
>>
>>
>> I would like to share some ideas I have to make our release plan more
>> clearer, public and well defined.
>>
>> This plan doesn't require additional work from the community (apart from
>> the due diligence when we will call for votes) because I will take care
>> about preparing release candidate files, sign them and call for votes; then
>> publish them if the vote is successful.
>> This is basically what we did in the last 2 years with the only (big)
>> difference that the release schedule will be decided and announced in
>> advance on fixed dates.
>> For example, we could decide that during the year 2012 (the same scheme
>> could be used for 2013 etc...) we will issue a release from each branch
>> every 4 months like this:
>>
>> * release 11.04 around 2012-04-15
>> * release 11.04.01 around 2012-08-15
>> * release 11.04.02 around 2012-12-15
>>
>> * release 10.04.01 around 2012-03-15
>> * release 10.04.02 around 2012-07-15
>> * release 10.04.03 around 2012-11-15
>>
>> * release 09.04.02 around 2012-02-15
>> * release 09.04.03 around 2012-06-15
>> * release 09.04.04 around 2012-10-15
>>
>> Or we could decide on a less aggressive schedule and release each branch
>> every 6 months etc...
>>
>> And we could also vote in advance for the time a release branch will be
>> closed: for example we could vote that the community will not release and
>> apply patches to the release branch 09.04 after the release 09.04.04 (this
>> is just an example as I would like to propose to close the 09.04 branch
>> earlier than this). New patches/contributions (always welcome) for that
>> branch (after it is closed) will not be applied to the branch and will stay
>> in Jira for interested parties (unless the community will decide to reopen
>> it).
>>
>> In this way users will know in advance when a branch will be deprecated,
>> how many bug fix releases will be issued and based on this information
>> could prepare in time for the upgrades (or switch between major releases).
>>
>> Of course there will be exceptions: maybe we will have to release out of
>> schedule to fix some major security issues or we could skip a release if no
>> changes since the previous one were committed etc...
>>
>> When the plan is in place we could then prepare a nice roadmap diagram to
>> be published in our Download page. The roadmap will not be feature based
>> and for this reason it should be doable with the current structure and
>> resources we have in the community: I know it would be also nice to plan
>> and work together on a features set, but this will definitely require more
>> coordination, agreement and effort... we can (and should) always try to do
>> that also but this is another topic (for another thread).
>> In the meantime, with this time based release plan we will have something
>> real to play with.
>>
>> Please let me know what you think.
>>
>> Thanks,
>>
>> Jacopo
>>
>
>

--
I am hongs