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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
