Procedure for a release build (was RE: [Ffmpeg-devel] Re: 0.4.9-pre2?)

[Dario Andrade]

> In gmane.comp.video.ffmpeg.devel, you wrote:
> > no, not everyone.  you forget that most users use packages.  do you
> > really think everyone who uses FFmpeg has the desire/ability to track
> > FFmpeg cvs?
> 
> E.g. Debian ships ffmpeg CVS snapshots instead of release tarballs.
> 

>From the good discussion about this issue, I would say that
although I am somewhat active in reading/updating ffmpeg cvs (almost
everyday), that proved to me and to my production process to be a very
unstable option, in several times.

Of course creating a package from time to time is useful, so I just think
that although it seems a lot of work, when it become a habit, it will be
much easier.

My suggestion follows.

Four parameters indicate version:

MAJOR.MINOR.INTERFACE.RELEASE (e.g. 1.3.5.89)

----------------------------------------------------------------------
MAJOR = indicates major architectural or user interaction change (changed at
will).

MINOR = indicates new programmed release (when new feature, codec, or better
API programming). An odd number means it is from current development cvs
tree (main trunk), even means a branched cvs tree, release version.

Following linux standard, an odd number indicates current CVS tree (main
trunk), with current development.
>From the first lines, MINOR is incremented to become the even version
(release version, branched on CVS, for bugfixes and package retrieval).
>From the last line, this minor version is incremented after being tagged, to
become the next development tree.

When the procedure is done, MINOR becomes an incremented odd number again,
and every commit should increment the RELEASE version.

INTERFACE = indicates interface change (binary compatility, function
prototype changes or anything that might modify way people program or
expect binaries to work, changed whenever one thinks that change could break
binary or syntatic bindings).

RELEASE = indicates every atomic change in cvs tree (I'd say incremented
every commit, except in the header file containing the version info).
When MAJOR or MINOR changes (as for a new release), RELEASE becomes 0 again.

When cvs branch is modified (e.g. for a bugfix on a particular release, say
1.2.1.5), RELEASE for that branch is incremented (1.2.1.6).
-----------------------------------------------------------------------

1) Increment the MINOR version (MINOR becomes an even number now, e.g.
1.2.1.0)

2) As MINOR has changed, RELEASE version is reset (RELEASE is 0 now).

3) Branch CVS using tag BRANCH_FFMPEG_<MAJOR>_<MINOR>_<INTERFACE>_<RELEASE>
(e.g. BRANCH_FFMPEG_1_2_1_0)
   (At this time, current development continues)
	
	a) Increment MINOR again in main trunk, and it becomes an odd number
again, indicating the current development (e.g. 1.3.1.0) At this time,
current development is still going on, no interruptions are necessary).

4) Do regression tests.

5) Pack distribution and announce it (FFMPEG
<MAJOR>.<MINOR>.<INTERFACE>.<RELEASE> RC1), e.g. FFMPEG 1.2.1.0 RC1
 
6) Wait for a complaint or bugfix (week?).

	a. If someones complains or there is a bug before the time
specified:
		i. Wait for bug fixes or suggestions/analysis of if it
should be fixed or not and how many days (wait for 3 days?).
		ii. If no fix, or decided not to fix, add to BUGS file.
	b. Merge the change into main trunk if appropriate (that's
developer's call).
	c. Go to number 4), now naming it RC2 (3, 4, and so on...).

7) Tag the branch being release as UNSTABLE (FFMPEG_1_2_1_79_UNSTABLE) and
announce it.

8) Steps 4, 5, 6 will be repeated several times while bug are being found.

8) After certain period of time without a bugfix or complaint (3 months?),
UINSTABLE becomes STABLE (e.g. FFMPEG_1_2_1_82_STABLE)

For a project that has only a few packed distributions for about some years
now of active development, waiting a month to make an unstable version, 3
months to name it STABLE, etc... is not a long time at all.

If someone has a better simplified approach, good.
Anyway, this could be a way for ffmpeg to start creating a robust,
development process.

Cheers,
Dario Andrade