| 1 |
Santiago M. Mola wrote: |
| 2 |
> On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <lu_zero@g.o> wrote: |
| 3 |
>> Ryan Hill wrote: |
| 4 |
>>> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when |
| 5 |
>>> 0.26 was released. I already need to do this with my live ebuilds. Of |
| 6 |
>>> course, with some projects you never know if the next version will be |
| 7 |
>>> 0.26.1, 0.27, or 0.3, or 1.0... |
| 8 |
>> That's an upstream issue, all we should care is about getting a version |
| 9 |
>> value that makes sense for us, better if it does for them. |
| 10 |
>> |
| 11 |
> |
| 12 |
> I think upstream use release branches correctly here, and it's the |
| 13 |
> most widespread use. |
| 14 |
> |
| 15 |
> There's some real examples where ".live" = "_pre" has problems. |
| 16 |
> |
| 17 |
> * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, |
| 18 |
> but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when |
| 19 |
> it's released. |
| 20 |
|
| 21 |
MPlayer has a psychological issue with 1.0 versioning, still 1.0.live |
| 22 |
correctly isn't higher than 1.0 |
| 23 |
|
| 24 |
> |
| 25 |
> * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. |
| 26 |
|
| 27 |
No, ffmpeg does "continuous release" every commit must not add |
| 28 |
regressions and the ABI/API is marked, a correct version for ffmpeg is |
| 29 |
given by taking the combination of the libraries major version. |
| 30 |
|
| 31 |
Every major version update I'll have to update the live ebuild because |
| 32 |
of that and this is correct. |
| 33 |
|
| 34 |
> |
| 35 |
> * x11-wm/enlightenment: latest release is 0.16.8.13, current live |
| 36 |
> ebuild is 0.16.9999. If we use ".live" here we'd need either |
| 37 |
> 0.16.9999.live (which is quite pointless) or 0.16.8.14.live which |
| 38 |
> would need to be updated after every minor release. 0.17.live is not a |
| 39 |
> possibility at all since 0.17 is a rewrite from scratch and an entire |
| 40 |
> different application. |
| 41 |
|
| 42 |
0.16.9.live sounds that bad? |
| 43 |
|
| 44 |
> With the current proposal, .live ebuilds should be changed after every |
| 45 |
> minor release, unless we use the number of the next release. |
| 46 |
|
| 47 |
You do pick what is good for you. |
| 48 |
|
| 49 |
> Next release isn't always known, and it's doesn't always make sense. This |
| 50 |
> puts us in a worse situation than with GLEP 54, or even with the |
| 51 |
> current use of .9999 components. |
| 52 |
|
| 53 |
I don't see how. Keep in mind that -9999 ebuild should just stay in |
| 54 |
overlay and shouldn't be used by average users. The should help us |
| 55 |
developer tracking projects and get us to the point of having a snapshot |
| 56 |
for common usage. |
| 57 |
|
| 58 |
|
| 59 |
lu |
| 60 |
|
| 61 |
-- |
| 62 |
|
| 63 |
Luca Barbato |
| 64 |
Gentoo Council Member |
| 65 |
Gentoo/linux Gentoo/PPC |
| 66 |
http://dev.gentoo.org/~lu_zero |
| 67 |
|
| 68 |
-- |
| 69 |
gentoo-dev@l.g.o mailing list |
Archives