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

[Kevin P. Fleming]

Luigi Rizzo wrote:

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

This is not something that I can imagine very many users doing, and
those that have the technical ability to do so can do this via copying
source modules instead of already-built binary modules.

Backporting of new features is not really something we *want* to make
easy; can you imagine how difficult it would be to handle bug reports
when people cannot say "I am running 1.6.5", but instead say "I am
running 1.6.5, but with app_voicemail.so from 1.6.3 and app_meetme.so
from 1.6.7"? If all of these modules were distributed as independent
entities with their own release schedules then this would make much more
sense.

Can you point to _any_ open source project that follows a model like
this and encourages users to mix-and-match modules from different
versions of their core project?

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

If the people who committed code took more time to get consensus on API
visible naming, stuff like that wouldn't happen.

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

That is the case today, and is the reason why this new policy is being
discussed in the first place! Users are reluctant to upgrade to
1.4.<anything> because it is so different from 1.2. Have you read
Russell's proposal? The goal here is that 1.6.<x+1> will have minimal
functionality changes plus bug fixes, and should be a small enough
incremental change that users _are_ comfortable trying it, and more
importantly, they can try it and revert without having to change config
files to go back.

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

This has already been proposed and discussed right here in this thread;
we intend to do *exactly* that, maintain a number of 1.6.x releases for
security fixes only. The exact number has not been agreed upon, but will
probably be at least three and no more than five.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)