I'd vote for a six months release cycle. ...in case we can actually enforce it.
----- Original Message -----
From: Olaf Siejka
To: ReactOS Development List
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev