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

[Luigi Rizzo]

On Wed, Oct 24, 2007 at 08:33:51AM -0400, Kevin P. Fleming wrote:
> 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.

clarification - I only care about source (and config file)
backward compatibility. My original post said API/ABI but
that was corrected above - as you see, i say API only.
This is, of course, as long as it is clear that "API" means prototypes
of functions and structs that are directly or indirectly exposed
to applications. 

This said:

   it is not that easy right now to upgrade from source, even within
   the same branch, exactly for that sort of API changes that occur
   so often, touch a zillion files and break source compatibility.

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

There is a huge difference between (excuse the capitals, they are
just to emphasize text in this long email) ENABLING, ENCOURAGING,
and HANDLING BUG REPORTS.

I was only suggesting that ENABLING backward/forward compatibility
has, in my view, very beneficial effects on the amount of testing
that we can get from users. If i have to say more, it makes life
easier too, because upon a change I, as a developer have a better
chance to identify whether something broke in the "core" or in the
individual module by just upgrading one of them. Right now it is a
lot harder.

I did not say we should ENCOURAGE this behaviour - leave that to
the users, and tell them they are on their own if they do that.

As for HANDLING BUG REPORTS - at the end of this email you are
mentioning that your plan is to support 3..5 versions of 1.6.X
with security fixes - wouldn't it be a lot better to have to
officially support just one version (but because of the API/source
code compatibility, it is a lot easier for customers to upgrade
the individual modules involved in the security fixes) ?


Now, if you disagree
> 
> 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?

It depends on how you see the relation between the asterisk "core" and its
"external modules". To me, they are related in the same way as an OS kernel
and userland apps; or X11/apache and their modules; and so on.

Now if you disagree with this view there is no reason to argue in
the first place. If you agree, then you see that pretty much any
system around doesn't care on what runs on what, as long as the
APIs are respected. Surely, when it comes to claining support one
can make an official statement that "only configurations A and B
are supported, for other configurations you are on your own", and
this is a honest and well sustainable support policy.

cheers
luigi