[MPlayer-dev-eng] release alongside FFmpeg

[Georgi Petrov]

On Mon, Feb 2, 2009 at 8:38 PM, Eric Appleman <erappleman at gmail.com> wrote:
> Reimar Döffinger wrote:
>> On Mon, Feb 02, 2009 at 05:27:07PM +0200, Georgi Petrov wrote:
>>
>>> I agree as well. If MPlayer adopts the 'WINE release method' is every
>>> new release going to be called 'MPlayer-1.0RC-YYYYMMDD' or more like
>>> 'MPlayer-0.99.1', 'MPlayer-0.99.2' and so on?
>>>
>>
>> I'd just go with
>> 1.1, 1.2, 1.3 ...
>> You know, leaving 1.0 out means we don't have to discuss what special
>> features we need in order to call it 1.0...
>> _______________________________________________
>> MPlayer-dev-eng mailing list
>> MPlayer-dev-eng at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>>
>>
>
> I forgot to mention this is in my last posting, but I highly recommend
> that we chose a versioning system that does not exhaust itself rather
> quickly.
>
> Going with 1.1, 1.2, etc. will cause problems even if a version 1.10 was
> reached because each release would indicate larger changes in code than
> may actually be present.
>
> Therefore, I believing using 1.1.x or 1.0.x as a trunk, would be ideal.

I'm pretty new to MPlayer development and by no means my vote has any
weight, but let me summarize what I think:

Making a new release will be a good thing, especially considering that
so many distros really package the last official release, which
happens to be dated October 2007.

Dropping the RC (and especially not producing another RC) seems like a
good idea as well. May be I miss something, but since I'm subscribed
to MPlayer, not THAT much development is happening, only now and then
something is fixed or something important like VDPAU is added. Don't
get angry at me, but most of the commits are commas, coding style and
such misc. things. I mean - the development is going slow. It doesn't
need to be fast, of course.

I don't know what exactly has to be done to qualify as "1.0", but it
seems that nobody is really waiting for such thing. This leads to
another thought - that making 1.0 soon (hopefully synchronized with
FFmpeg's release) sounds logical. It has to be done sooner or later
anyways.

About the future release cycle - I'm not the one who should write
about it, but again - I think that automated script, which makes a
snapshot every two weeks or 2 months or whatever is good enough. Just
make sure anything compiles clean :)

New versions doesn't have to be that much different from the old ones,
but this way MPlayer could establish a "interface with the rest of the
world", so anybody (distros included) could grab .tar.gz with the
latest changes and not wait 1 year just to get a lame bug fixed. And
no, no one likes to download from SVN, grab all those additional
needed libraries, inspect that the configure script have found
everything they need and so on (which is distro's work anyway).

I don't understand - what's the problem with releasing more often
(weeks, months) instead of once per year? And really - going forward
with 1.0, 1.1 (or 1.0.x and 1.1.x) and so on is good from repository
point of view as it enables easy future repository-friendly version
control. With the current - once per year release cycle there's no
need for a real version-friendly designation anyway :)

I don't want to be offensive to anyone - I just write what I think,
which of course doesn't mean that it's the right thing to do. I leave
this to the guys, who maintain MPlayer and know what's the best
decision. I tried to give an alternative point of view.