I approve of anything that we will stick to. A six month cycle sounds good.
On Sat, Oct 9, 2010 at 9:14 AM, Olaf Siejka <cae...@gmail.com> wrote: > 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@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- <+encoded> if you square a unicorn do you get a real animal?
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
