On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller <u...@gentoo.org> wrote: > > And on what basis would you stabilise Portage, when there are no > ebuilds in the tree to test its EAPI 6 code? >
As long as the EAPI6 code in the new portage is no more broken than the EAPI6 code in the current stable version of portage (which doesn't work/exist at all), it isn't much of a regression. What would be more of a pain is dealing with fixes in stable. But, I don't have a problem with starting to use EAPI6 now, mainly because the ~arch version of portage does not require any new ~arch dependencies that would create a mess for stable users. So, if a user needs to switch to a newer portage for a month or two it shouldn't be that big of a deal. Actually, what is less clear to me is how portage versioning actually works, or if we attach any meaning to the version numbers at all. Both the stable and unstable series are on 2.2.x, but there are no versions in the tree between 2.2.20 and 2.2.23. The main thing I find painful in following ~arch on the odd package is when maintainers drop versions quickly after bumping them. That tends to result in a situation where if you follow ~arch you end up having to accept lots of updates because none of the versions stay in the tree long enough to actually get stabilized. Unless a ~arch package version is so broken that it could never be stabilized it is probably better to leave them there so that it is easier for users to drop back from ~arch to stable without downgrading. -- Rich
