Per some discussion on IRC, I am bring stablizing 2.1 at the pre9 or pre10 branch to the table. Reasons for doing so include:
2006.1 - They say if 2.1 is to be in 2006.1, mid-july Xorg Modular - They cannot stable xorg modular until 2.1 is stable FreeBSD - Their entire port depends on features and bugfixes in the 2.1 series Feature use - People are already running/using features in 2.1 to the point where we have had to backport features and do -rX releases of a dead codebase ( 2.0.54 ) For these reasons I request we release pre9 as an rc canidate, set a feature freeze, and then stable it. During this a 2.2 branch can be created for future development with this codebase. Why Branch at 2.1_pre9? Manifest2 is already in the tree and needs refinement. Branching at pre7 is also a canidate, but i would rather press for keeping manifest2 in the tree and fixing up it's code instead. TimeLine: If all goes well, we can do an rc sometime this week: May 3rd : RC1 May 6th : RC2 May 9th : RC3 May 12th : RC4 May 15th : RC5 May 18th : RC6 May 21st : RC7 May 24th : RC8 May 27th : RC9 ( if needed ) May 30th : RC10 ( if needed ) June 5th : ~arch sys-apps/portage-2.1 July 6th : sys-apps/portage-2.1 Problems: We may miss the timeline and thats ok. Releng wants a working portage, not a bugging POS portage-2.1 that wasn't ready for release. This timeline is relatively tight and I think it's a nice goal to set, it's not imperative that we reach it. Comments, Questions, opinions? -Alec -- gentoo-portage-dev@gentoo.org mailing list
