[MPlayer-dev-eng] Re: Versioning scheme

Aurelien Jacobs aurel at gnuage.org
Mon Sep 19 13:31:33 CEST 2005


On Mon, 19 Sep 2005 12:23:26 +0300
"Andriy N. Gritsenko" <andrej at lucky.net> wrote:

>     Hi, Alex Beregszaszi!
> 
> Sometime (on Friday, September 16 at 23:56) I've received something...
> >While talking on irc a lot about history, releases and versions, I'm
> >going to make an idea public for comments.
> 
> >In the past we had "stable" releases every half or one year. The last
> >one was 2 years ago..
> 
> [.......]
> 
> >What do you think?
> 
>     I don't like idea to have major version changed a lot.
> Minor version may be changed, of course.

Lots of people agree with that. That's why Alex proposed a solution
with only year.quarter. There is no major/minor anymore !

> May be, it's good to have something alike
> of 1.0.2 where 1 is minor version is constant for current project, 0
> is the year (since 2005) and 2 is subversion, i.e. half of year or
> something more if there were some big changes in release before half
> of year. :)

That's exactly what Alex proposed, except for those points:
 - he simply omitted the initial 1. with your proposition it would
   NEVER change anyway, so there's no point writing it.
 - he begans numbering with year 2000 instead of 2005 (this is more
   "natural" for people which are not inside of the project)

I personally like Alex proposition. (except that I may prefer year.month,
as it allows more granularity (2 releases in the same quarter), but this
is not very important).

Anyway, with current MPlayer development process, using major.minor has
no sens, as there is no roadmap, no stable vs. development branch, only
anarchic addition of random features and bug fixes.

Aurel




More information about the MPlayer-dev-eng mailing list