Thu Jan 29 17:39:18 CET 2009
On Thu, Jan 29, 2009 at 8:36 AM, Aurelien Jacobs <aurel at gnuage.org> wrote:
> On Thu, 29 Jan 2009 15:06:47 +0000
> Robert Swain <robert.swain at gmail.com> wrote:
>> 2009/1/29 Aurelien Jacobs <aurel at gnuage.org>:
>> > On Wed, 28 Jan 2009 20:35:20 -0800
>> > Mike Melanson <mike at multimedia.cx> wrote:
>> >> Diego Biurrun wrote:
>> >> > Let's get the two biggest bikeshed topics out of the way right now:
>> >> >
>> >> > - release date: weekend 2009-02-21/22
>> >> > - release name: 0.5
>> >> >
>> >> > There, progress, it feels so great...
>> >> Awesome. No argument here. Does anyone have a reason why we shouldn't go
>> >> with 0.5 for a release?
>> > Why 0.5 ? Is it to make people think this is the successor of the
>> > (never released) 0.4.9 ? IMHO it is not the successor of 0.4.9, it
>> > is much more than that.
>> I think this part of your argument is where the bike shed discussion
>> will begin.
> Did someone really expected that we could make a release without
> such a bikeshed discussion ?
>> Trying to apply a number that has sufficient meaning to
>> represent what has happened since the last release. I think this is
>> pointless and we should rather consider this the first release and
>> have its version number just be something. It doesn't matter what the
>> number is.
> Absolutely agree ! That's what I tried show.
> And unfortunately it sounded like 0.5 was proposed for some emotional
> reason (which we should try to avoid IMO).
>> > 0.5 can also be confusing related to the library major number. People
>> > will wonder, "hey, I downloaded 0.5 but I still only get libavutil49 !"
>> > (IIRC 49 was derived from 0.4.9)....
>> This is possibly a reasonable point. I think ideally the library
>> version numbers should be linked to the release version number
> That's hardly possible as we reaffirmed recently that we will try to
> ensure that each lib can evolve independently from each other (ie.
> bumping major of one lib won't bump major of other libs).
>> we should just document the library version numbers that correspond to
>> a particular release.
> This would probably be useful, and should be part of the release process.
>> > The alternative to avoid any confusion and any discussion about how
>> > much we increase the number at each release is obviously to use date
>> > as the release number (be it Y.MM or YYYY.MM or YYYYMMDD).
>> > It seems I'm not the only one who think it would be better:
>> > http://multimedia.cx/eggs/gaining-momentum/#comments
>> I'd be happy with a date (YY.MM or so) or "Release NN". We don't
>> intend to make bugfix releases so I think something like this would be
>> more suitable than 0.5, but I don't really care about the number.
> I don't really care either, as long as there is the fewest possible
> emotion involved in choosing next version number.
> So I care more about having a strict, regular rule for choosing next
> version number, than about the first version number itself.
> The goal is to avoid lengthy discussion at each release.
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
I like the date idea because it:
1) Provides inherent information on time of release
2) It's an easy to remember number.
3) It's strictly increasing.
4) It eliminates all possible arguing, ever, because there's no
bickering over major/minor numbers.
More information about the ffmpeg-devel