On Fri, Jan 28, 2005 at 05:13:00PM -0800, Jeremy Huddleston wrote: > On Fri, 2005-01-28 at 14:44 -0800, Brian Harring wrote: > > Basically, portage releases (upstream, the actuall tarball naming) > > needs to drop the -r* version component. > > I've been thinking that for a long time now... Why not jsut start it > with the next release: 2.0.51.16 Thats what I was thinking. 4 version components is annoying, but neh. I'd rather correct it now, then wait for it next time around (and potentially not do it next time around).
> Also, I think it'd be wise to have more branches in cvs and tag every > release (not just some of them): Tagging every release should occur with every release imo. Branches are addressed below > So things going into the next "minor" bump (2.0.51 -> 2.0.52) can go > into portage_2_0 and we can make the 2_0_51_branch just regression > fixes. Then when portage_2_0 is ready for testing/feature-freeze, we > branch it off to 2_0_52 branch and portage_2_0 becomes what will be in > 2.0.53... Down the line, branching head from stable (when it's actually stable) makes sense... won't happen with the next branch since there's already around 450kb+ worth of changes in head, and that changeset will grow :) An ancillary issue, possibly worthy of it's own thread is mandating stable, be just that- stable. Only bug fixes, and regression fixes. The result of the ebuild digest going from generating a complete digest (all src_uri), to a partial digest (src_uri after USE flag filterring) fex, should not ever change within a stable release (as it did at .51-r3, and subsequently reverted recently). Granted, I would make an exception here and there- the locking changes to portage_db_flat now in cvs- in that case, it's an improvement of existing code, changes are minor, and the gains from it are noticable- roughly 13% normal usage, in rare/screwed up systems, dropping metadata transfer from 20m to 3m. That said, still not much for anything but reversion/bug fixes in stable :) ~brian -- [email protected] mailing list
