Luca Barbato schrieb:
Santiago M. Mola wrote:
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.
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@lists.gentoo.org mailing list
