[FFmpeg-devel] Release

Stefano Sabatini stefano.sabatini-lala at poste.it
Fri Jun 17 02:52:53 CEST 2011


On date Thursday 2011-06-16 22:49:59 +0300, Ivan Kalvachev encoded:
> On 6/16/11, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> > On date Thursday 2011-06-16 11:33:33 +0300, Ivan Kalvachev encoded:
> >> On 6/16/11, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > Hi
> >> >
> >> > We will make the 0.7 oldabi & 0.8 master releases soon
> >> > (yes now really) ;)
> >> >
> >> > if you know of serious bugs, fix them now, or report them
> >> >
> >> > ill update oldabi tomorrow, this will need testing to make sure its
> >> > compatible with old abi/api so please help with that if you care about
> >> > oldabi.
> >> >
> >> > thx
> >>
> >> I have one line fix for bink audio decoding in mplayer. (ffplay itself
> >> is not affected, probably). I'll send it right away.
> >>
> >> I have a proposal for a numbering scheme.
> >> Let's release:
> >>
> >> 0.7 - old abi
> >> 1.7 - new abi.
> >>
> >> The meaning is simple. The major number indicates abi/api
> >> compatibility. While the minor number indicate feature completeness.
> >> This way user could easily compare different abi interfaces without
> >> getting in confusion what is newer and what is older.

Basically you're proposing to adopt this scheme:
* major indicates API compatibility, it is increased when the API/ABI
  is bumped

* minor indicates addition of features/symbols

* micro indicates minor fixes

So this is what I would expect:

* old-abi -> 0.7
* master  -> 1.0 -> new branch, breaks API/ABI compatibility with
  the 0.X branch.
* we'll increase micro in case of minor changes, e.g. we would have
* 0.7.1, 0.7.2, 1.0.1, 1.0.2,...

What bugs me is that:
1) we didn't follow this scheme for the 0.5/0.6 releases (0.6 was not
   API/ABI compatible with 0.5)

2) it's not sure that we will break API/ABI again in $release_period,
   so you end up with 1.0.X, 1.1.X, etc., it becomes difficult to
   follow the numbering logic for the casual user

3) people are used to expect a simple numbering scheme, a sequential
   scheme serves the purpose quite well, release notes should document
   what's in and what's out in the release, with particular mention to
   interface changes.

> >>
> >> Aka in future 0.7.1 may be 0.7 with just security patches, while 0.8
> >> would be oldabi with new features (if we still support it).
> >
> > I prefer to keep the current simple naming scheme, going from 0.6 ->
> > 0.7 / 1.7 is just confusing, and we have already the library version
> > numbers to indicate API/ABI compatibility.
> 
> Library version numbers are well hidden in the source/binaries.
> 
> The new numbering is less confusing than making 2 new incremental
> releases with (almost) same feature set.  The similar second numbers
> would instinctively hint users that these releases are somehow
> similar.

Uhm so you have:
0.7.0 -> 0.7.1 -> 0.8
1.7.0 -> 1.7.1 -> 1.8

but now the relation between 0.8 and 1.8 is lost, unless you want to
synch the various branches, which looks like a very bad idea for who is
going to actually do the work (TM).

Also having 0.7 and 1.7 will cause immediate confusion, people will
start to wonder what happened with 1.0, 1.1 ...

> The major number is routinely increased when program/project goes
> under rewrite and breaks compatibility. We use it in similar meaning.

We are expected to break compatibility more or less in each release,
altough we strive to reduce the amount of pain inflicted to users in
the update process.

0.7/0.8 dual release is a bit like an anomaly, given the royal mess
occurred in the first half of 2011 it hasn't been possible to manage
the things more sanely and this solution looks to me like an
acceptable compromise.

> Also, what number should we use if for some reason we decide to make
> another full release with the oldabi?

I don't see so many developers willing to do releases and extending
old branches, also what would be the point of that?

> 0.7.1 should be maintenance
> only, like the previous 0.5.x 0.6.x used to be ;)
> 
> FFmpeg project is over 10 years old, maybe it is time to abandon the
> 0. prefix ;)

Major number is used only for marketing moves, you may call it indeed
marketing_number.

> Well, Doing 0.7 and 0.8 is acceptable, but please, give a little bit
> more thought of my proposal.
-- 
FFmpeg = Fostering Fancy Mere Pacific Emblematic Glue


More information about the ffmpeg-devel mailing list