On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote: > Ryan Hill wrote: >> >> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when >> 0.26 was released. I already need to do this with my live ebuilds. Of >> course, with some projects you never know if the next version will be >> 0.26.1, 0.27, or 0.3, or 1.0... > > That's an upstream issue, all we should care is about getting a version > value that makes sense for us, better if it does for them. >
I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where ".live" = "_pre" has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.9999. If we use ".live" here we'd need either 0.16.9999.live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. * media-sound/amarok: live version is 1.4.9999. Next version is 2.0, but that's a different branch so I'd expect 2.0.live to give me the latest 2.0 version available, not 1.4's. With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of .9999 components. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
