[MPlayer-dev-eng] [RFC] Versioning scheme

[Rich Felker]

On Fri, Sep 16, 2005 at 10:59:27PM +0200, Alex Beregszaszi wrote:
> Hi,
> 
> 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..
> 
> But most of the stable releases were of lower quality than most pre
> releases, so we wanted to have our pre releases taken as stable ones.
> Nowadays most packagers take them as semi stable ones, so this mission
> looks accomplished. However, we wanted to have better release versioning
> than the neverending 1.0pre666.
> 
> I propose the following: year.quarter. E.g. MPlayer 5.4 for 2005 fourth
> quarter release. Look, we can reach 6.4 in a year!
> 
> At least this is consistent, but gives us a bit of freedom aswell: we
> can decide in which of the 3 months of a quarter to release. These
> should be like a bit more stable releases than the current pre ones.
> They could utilize 1-2 rc releases before the final ones.
> 
> A possible scenario from now on:
> 
> * make 5.4pre1 next week (we plan to do a release very soon)
> ...
> * make 5.4rc
> ...
> * make 5.4 when mplayerhq arrives
> 
> * make 6.1pre1 in january
> * release 6.1final in february/march
> 
> So like every second half of a quarter it could be released.
> 
> What do you think?

Totally against. All this amounts to is version number inflation, and
in fact it makes the version numbers meaningless. They have no
correspondence to how complete the program is or how much has changed;
they just represent time. If we're going to go down the stupid
microsoft path and version our software by year, we might as well just
use cvs snapshot dates as release versions. Then we can have version
numbers in the 20-million range and be even more inflated than RedHat
and such shit...!!

Rich