Luca Barbato schrieb:
> Santiago M. Mola wrote:
>> 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.
> 
> MPlayer has a psychological issue with 1.0 versioning, still 1.0.live 
> correctly isn't higher than 1.0
No, it is not.

Take KDE for example, they have trunk currently, that will become KDE 
4.1.0. When that has been released, there will be a branch 4.1, which is 
ahead of 4.1.0 and will become 4.1.1, then 4.1.2 (when 4.1.1 has been 
released) etc.

In the -scm approach this means:
trunk = -scm
4.1 branch = -4.1-scm

With your approach, we would have to fix the version after every 4.1.x 
release. That sounds awful, tbh. So:
trunk = .live
4.1 branch = 4.1.1.live (before 4.1.1 has been released)
4.1 branch = 4.1.2.live (before 4.1.2 has been released)
4.1 branch = 4.1.3.live (before 4.1.3 has been released)
...
-- 
gentoo-dev@g.o mailing list