[ros-dev] ReactOS development cycle

Javier Agustìn Fernàndez Arroyo elhoir at gmail.com
Sun Oct 10 14:29:52 UTC 2010


+1 for a 6-months cycle.... 0.3.12 is actually taking more than 4 months
(even more than 6 months, but isnt usual)

On Sun, Oct 10, 2010 at 1:09 PM, Kamil Hornicek
<kamil.hornicek at reactos.org>wrote:

>  I'd vote for a six months release cycle. ...in case we can actually
> enforce it.
>
> ----- Original Message -----
> *From:* Olaf Siejka <caemyr at gmail.com>
> *To:* ReactOS Development List <ros-dev at reactos.org>
> *Sent:* Saturday, October 09, 2010 3:14 PM
> *Subject:* [ros-dev] ReactOS development cycle
>
> I think its a good time to discuss current development cycle.
> It become clear to me, that there is no way we can currently adhere to 3
> months development cycle. Its pointless to stick to something we managed to
> succeed only once or twice.
> Agreeing with the fact we do need releases, for various reasons, i would
> like to propose a new, longer cycle.
>
> The most apparent choices to me are 4 and 6 month ones. At least half of
> the cycle would be spent on all out development, with the following half
> turning its concentration to stabilizing trunk, searching for regressions
> and bugs, fixing them. The cycles would be separated by branching the
> release version. The actual release would be taking place on the first month
> of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing
> changelog etc. One month is more than enough, to release two RC (at the
> branching and next one - after two weeks). End of the month must result in
> final release. RC should be rather released internally for testing purposes
> on a default iso.
>
> The actual proposals are:
>
> 4 months:
>
> month 1: Development on version x. At the same time, the Release x-1 is to
> be final-tested, emergency-hacked, changelogged and shipped. The deadline is
> end of month 1.
> month 2: Development on version x. All development that can affect trunk
> stability, but also will not be shipped with the release X should end or be
> limited to branch only by the end of this month;
> month 3: Switching from development more to stabilizing trunk, searching
> for regressions, fixing bugs. Finalizing sub-projects that are to be
> included in release x;
> month 4; No new functionality/code, bug-fixing and hunting regressions.
> This month should end with branching for release x;
>
> 6 months:
>
>  month 1: Development on version x. At the same time, the Release x-1 is
> to be final-tested, emergency-hacked, changelogged and shipped. The deadline
> is end of month 1.
> month 2: Development on version x;
> month 3: Development on version x. All development that can affect trunk
> stability, but also will not be shipped with the release X should end or be
> limited to branch only by the end of this month;
> month 4: Switching from development more to stabilizing trunk, searching
> for regressions, fixing bugs. Ongoing development work only for features
> that are to be shipped with release x;
> month 5: Switching from development more to stabilizing trunk, searching
> for regressions, fixing bugs. Finalizing sub-projects that are to be
> included in release x;
> month 6: No new functionality/code, bug-fixing and hunting regressions.
> This month should end with branching for release x;
>
> ------------------------------
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20101010/67d70211/attachment.htm>


More information about the Ros-dev mailing list