On Sun, Jan 30, 2005 at 09:33:44PM +0900, Jason Stubbs wrote: > On Saturday 29 January 2005 07:44, Brian Harring wrote: > > Why? Because that component is used by the ebuild maintainer, so that you > > can have multiple revisions of an upstream version, fex, to include patches > > in the revision of the -upstream- release. Basically, an addition version > > component for ebuild maintainers to fool around with, yet the same pkg > > release. > > I hate to appear to "switch sides", but from here on there's isn't really > anything in the way of reasoning for dropping the revision component. The point I was trying to stress is that by using a tree convention (-r*; yes other packages use it, by they are a very -small- minority) for the upstream release, the benefit of -r* is lost for the ebuild/tree maintainer. Basically, that by using -r* in the actual portage release version, the ebuild maintainer is backed into a corner and forced to do some of the distasteful/bad things I mentioned later on. The distasteful/bad things mentioned later on, pretty much are general complaints, not strictly tied to version'ing scheme. That said, I'm inclined to think the various hacks slide by because there is no way to do a portage release (in the tree) that doesn't match an actual upstream/tarball release (backed into the corner bit).
> > Portage releases happen, but so do bugs, and there isn't any reason why we > > -shouldn't- be able to revbump a portage release (in the tree) so we can > > include patches. To head of the "well, we'll just do a release with the > > fix", yeah, that may be, but going by past experiences, time between > > releases is somewhat variable, regardless of bugs. > > This is unfair in this context - or at least unclear. The recent delays are > an > issue (as is including new features when there are still urgent bugs to be > dealt with, or changing the behavior of important dev features without > speaking with devs) but it is a separate issue and so should be dealt with > separately... Not meant to be fair, nor unfair; merely a statement of what is. Bugs happen, portage releases (.49, .50, and .51), due to time constraints, aren't always local to the time of the actual fix, eg, bug fixed on N, release within N + 10 days +/- 5 days. Case in point, recall the # of bugs that sat fixed in cvs for month+, waiting for a .50-r11 release? Some being rather serious (content borkage iirc), others just user visible and annoying (duplicate emerge -vp IUSE flags). The intention isn't to slander, or slap. It's merely to state, "taking this as a given, here is the benefits from what I propose", just that. The benefits in this case being that getting fixes out to the users isn't tied to a tarball release- the existing version could be revbumped, and fixed. > I don't see a need to drop the revision componently immediately. It makes > more > sense to me to run with what's happening at the moment and to move to a saner > versioning scheme on the next non-bugfix release - ie to 2.1.0. Possible, as stated while I'm aiming/blaming the current version scheme, the main beef is with slipping fixes/changes out w/out any form of a version bump. Additionally, the inability to release any changes without a upstream release- aside from how -r14 was handled, addition of a patch to fix a problem is completely acceptable (hell, preferable, the fix is out rather then waiting for an upstream release, less borkage/complaints/hair-pulling). If the -r* component is left, then either upsteram must start skipping versions (since it abuses -r* itself) so fixes can go out w/in the tree, or no patches/fixes are every put in the tree- releases in the tree are 1:1 with upstream releases. Or, the ebuild starts doing funky things with versions, eg -r140 -r150, etc. All 3 options suck imo, but as stated above, we're again backed into a corner. Whichever option being the end result (we change, we don't, we sort of change), the changing w/out version bumping of the portage ebuild shouldn't happen again- theres just too many way users can get screwed out of it, and theres no reasons -not- to use the auto-detection of version upgrades portage itself provides. We wrote/support the functionality, it's a bit daft not to use what we supply. ~brian -- [email protected] mailing list
