[asterisk-dev] merge policies, supported branches, API/ABI freeze (was Re: Asterisk 1.6 Release Management Proposal)

[Luigi Rizzo]

On Mon, Oct 22, 2007 at 05:29:40PM -0500, Russell Bryant wrote:
...
> I have been thinking about this, and I do not think that an API/ABI freeze is
> something that I would like to do for Asterisk 1.6 at this point.
> 
> As has been pointed out in other parts of this thread, trunk should always be
> usable.  It may have a few rough edges, which I am hoping that the 1.6 process
> will help alleviate.  I essentially want 1.6.X releases to be release-worthy
> snapshots of trunk.  Take a snapshot of trunk, get a bunch of people to test for
> rough edges introduced in the last month or two of merging new things, and
> release it.  I don't want to impose anything that will hinder development on 1.6
> quite yet.

i hope you'll reconsider this position.

The point of an ABI freeze (which doesn't have to last for life,
but at least for a reasonable period of time) in a -stable version
is not to make development difficult, but to make the upgrade path
less risky while at the same point improve stability.

If [at least the important] APIs in your system are stable across subreleases,
the user wouldn't mind so much upgrading to 1.6.X+1 - in case some of the
pieces he needs becomes broken, he can easily downgrade it to 1.6.x or
earlier. Similarly, if you have a new feature in 1.6.x+1, it is easy to
import just it.

For users, it is an incentive to upgrade, as they usually win.
For us developers, this means more and earlier testing - and of course
it requires a bit more discipline in coding, but often this also stops
gratuitous changes, e.g. global renaming of functions such as the
recent AST_CLI -> AST_CLI_I_LIKE_THIS_BETTER [just as an example].

With a monolitic system (as asterisk is now), you can't do any of the above:
if you upgrade, you have to take X+1 with all bells and whistles, and if
something breaks in the process (because if you want to make a release
only when the 100+ different pieces of code are "perfectly stable" you
never will), you have to downgrade everything. As you can imagine, users
now will be a lot more reluctant to upgrade because it might turn out in
a waste of time.

Note, the above reasoning applies especially for security fixes - unless
you want to maintain a bunch of 1.6.x, any vulnerability essentially
forces users to upgrade to the latest 1.6.x, irrespective of how good or
bad that release is for them. With the 'frozen API' model, they have a
much easier life adapting the security-fixed version to the version they
used to run.

	cheers
	luigi