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

[Roberto Togni]

On Fri, 16 Sep 2005 22:59:27 +0200
Alex Beregszaszi <alex at fsn.hu> wrote:

[...]
> looks accomplished. However, we wanted to have better release versioning
> than the neverending 1.0pre666.

Agree. The main wrong thing about current scheme is that it looks like
we're trying to reach 1.0. That's not true. Those are not 1.0pre
versions, we're still doing big changes, and it's not true that preX is
more stable than preY (with X > Y).

> 
> 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.
> 

Looks ok.
Also using a date (MPlayer_20050916) could be good. Pro: you "feel"
that the MPlayer you're using is old; Con:  it's much harder to
remember.
Or codenames with no number. Pro: easy to remeber, looks nice; con:
unsorted (is nameA older than nameB), big flames over name choice.

But let's try not to fight over naming and look a bit deeper at release
process.


[...]
> So like every second half of a quarter it could be released.
> 
> What do you think?
> 
Unsorted random thoughts.

Some math: 4 quarters per year, 1 release with one pre and one rc per
quarter, it gives 12 releases (ok, 4 releases, 4 pre and 4 rc) per year.

Too many.

And it also ignores security fixes releases.

We did 3 release (pre4 to pre6) and a security fix (pre5try2) in 2004,
and one release (pre7) and one security fix (pre7try2) in 2005 (up to
now).
pre8 (maybe with a different name) will be in 2005, and maybe pre9 too
(but don't hold your breath on it).


How long does it take to make a release? (based on past experience)
- Announce at least one week in advance, as told in release.txt.
- Flush the "harmless bugfixes" patch queue
- Flush the "somebody have to test it" patch queue
- Let the doc people update everything
- Delay release to fix the mess we just made
- Get a volunteer to update changelog and make ffmpeg changelog
- Make a "test" tarball, try to get someone to test it
- Try harder, expecially with people with uncommon hardware
- Test some common formats, a few net streams, and some weird samples
- Get someone to write a newsentry
- Made a new tarball, at least test-compile it
- Try to get everything ready
- Delay it until tomorrow because it's too late at night
- Release
- Let binary packagers some time to build their stuff

- Do some developement, and start thinking about next release

It may sound funny, but it's mostly true :)
From my past experiences (starting with pre4) this all takes at least
3-4 weeks from announce to release.

Considering also that releases should be targeted to Friday or Saturday,
because more devels are active and have less timing constraints, I
guess the "pre, rc, release" cycle to last at least a month and
half.


How is the release process going to be?
Release pre from cvs, release rc from cvs, and do release from rc?
Or fork at pre, and do rc from pre and release from rc?
I'm against freezing cvs, better to fork and have to backport
fixes (even if i don't like the extra work).


How long from pre to rc and rc to release? One week? Two?
Too little time -> nobody will look at them, too long -> cvs will drift
away from the tarballs.


Unless we have some "testing group" (who? not devels, they use cvs;
some "trusted users" group?) i don't think pre and rc have much sense,
expecially if me make an high number of releases. Who's going to
download and compile pre and rc, knowing that an "official" release
will happen soon? Not packagers, and probably not users (advanced users
will keep using cvs).


That all assuming release != random snapshot, else we can have mphq
doing releases for us automatically. Even better, we already do that,
but it's called daily snapshot instead.


Ciao,
 Roberto