+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.horni...@reactos.org>wrote: > I'd vote for a six months release cycle. ...in case we can actually > enforce it. > > ----- Original Message ----- > *From:* Olaf Siejka <cae...@gmail.com> > *To:* ReactOS Development List <ros-dev@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@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
