On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <lu_zero@g.o> 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: cooldwind@...
-- 
gentoo-dev@g.o mailing list