I still think you should stick to a 3 month cycle. If you want a stable tree and good exposure, you need to release often. It hasn't gone to plan in the past but I think things should start to stabalize going forward.
6 months is definitely not an option IMO. Ged. On 10 October 2010 12:00, Aleksey Bragin <alek...@reactos.org> wrote: > I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 > months is too long time between releases (we are speaking about normal > development, not kernel rewrites which have to take that long time). > > WBR, > Aleksey Bragin. > > > On Oct 9, 2010, at 5:14 PM, Olaf Siejka 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 >> > > > _______________________________________________ > 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
