[Asterisk-Dev] Stable vs Development releases

[steve szmidt]

On Wednesday 02 March 2005 21:56, Greg Boehnlein wrote:
> > The problem is stable is old and is missing alot of the features people
> > are wanting.  Honestly we run CVS-HEAD without fail.  I can get WEEKS
> > of uptime and no crashing
>
> Weeks? :) I measure stability for my boxes in years of uptime, not weeks!
>

Exactly. (Well, I never get years as maintenance forces upgrades every now and 
then. But without those it should run for years.) 

Some seem to lack the understanding of how a standard reliable development 
cycle looks like. So to no one in particular I offer these notes.

In essence one establishes what a program is supposed to do. A "roadmap" if 
you please. Then develops towards that. Once achieved you stop coding and 
concentrate on removing bugs. When happy with testing you release version 
1.0.0. And so on.

Sometimes there are various reasons that results in features being added after 
the first roadmap has been drawn. Stricktly speaking they should be added to 
a later release, but often various pressures pushes them in anyway.

One should always create a roadmap and not just randomly add features/changes 
to it. This makes for a predictable release schedule, and more stable 
software.

Backporting features is only done with stable and proven code. Of course, if 
the development is not managed well, backporting can be hazardus. In my 
experience managing is more demanding than coding. 

(In fact we often wrote bug free code, with typos being the most common bug. 
It was accomplished by simply ensuring the coder knew his tools/language 
fully and did not have any misunderstoods or uncertainties. Then clear and 
precise instructions of what was needed from him produced good code. It's too 
easy to be lazy and not manage your cycle properly, with sloppy code or 
functions as a result.)

Another easy example is to look at the kernel development. There you see a 
feature freeze is called, testing and debugging is done and a stable version 
is released. IT staff, fortunate enough to be able to, then test in their 
turn before putting it into production at their office.

Look at the version numbers of kernel releases. You can easily see the version 
number and when a patch has been added. Not using a good standard versioning 
system is confusing and results in less happy people.

With a good versioning system one can simply upgrade and use whatever you want 
to use and remain stable. Without it you don't know if you are the crash doll 
for patches or on the actual stable kernel release.

So you have primary release number, like 1, 2 etc. Then a minor release number 
after the 1st period which also shows if it is stable or development version. 
After that you have another period to indicate bug fix release.

After that you can have a dash which tells you what patch (or special release) 
you have. For example Alan Cox versions have AC and a number so you can tell 
it's his version. A changelog should accompany them so one can tell what's 
different.

From my point of view (as a non developer here); With Asterisk we saw a long 
development before we finally got a stable version. This was probably mostly 
due to the fact that the developers were mostly developing something they 
enjoyed doing, rather than towards a specific list of items, or use. 
Eventually pressure forced the 1.0 release to become a reality.

Stable should never have anything but proven code in it. It does not matter if 
it lacks nice, pretty or powerful things found elsewhere, the point above all 
else is that it is stable. It's predictable.

The fact that Asterisk has such a relative stable HEAD is only a boon to the 
developers. Besides, from a practical point of view, Asterisk has so many 
features beyond what most people ever use, there's no reason to be unhappy.

My customers only see stable, and that keeps them happy.
-- 

Steve Szmidt

"They that would give up essential liberty for temporary safety 
deserve neither liberty nor safety."
                                Benjamin Franklin