On Saturday 29 January 2005 07:44, Brian Harring wrote: > Hola y'all. > This has been requested, and discussed before, but bringing it up again. > Basically, portage releases (upstream, the actuall tarball naming) needs to > drop the -r* version component. > > 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. > 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... So, the -r component can be used for adding patches to the released tarballs. What benefit does that offer? Never mind, I'll answer that. It means that everybody that works on portage is aware what sources the release was made from. Changes in any revisions to the sources can easily be identified by looking at any patches. > Or, you get emails to -core/-dev telling people to re-emerge an ebuild. > Re: sticking the change into the existing revision in the tree, this is > naughty, oh so naughty. Tree policy states that if an ebuild is changed > such that the contents of what are installed are changed, the ebuild -must- > be revbumped, with one exception- typically, package.mask'd ebuilds (the > most unstable, of unstable ebuilds that are under active development). Exactly what the revision component should be used for... <snip> > So yeah, my two cents. At the time 2.0.51 as being conceived for release, > I (and others) brought this up- the -r* release strategy stuck. I'm again > pointing out the issues with it, and requesting the portage release version > scheme be adjusted. At this point, it would involve having 4 version > components- yes it's a pita, but that's the case atm for correcting it. > > Later releases could use a slightly saner major.minor release versioning, > eg 2.1 instead of just building upon 2.0.x . Either way, I don't care as > much about the versioning (major minor? major minor + extra component?) > used, as long as it drops -r*, and the changing the ebuild w/out revbumping > is stopped. 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. Regards, Jason Stubbs -- [email protected] mailing list
