[Asterisk-Dev] Time to lock down v1.1?

[Steven Critchfield]

On Fri, 2004-05-28 at 12:39, Linus Surguy wrote:
> > 1.1 (today's head) is more of a "let's try if this works' release.
> > Please spend time testing it. Remember, CVS HEAD, is not meant to be
> > stable. Now and then, it might not even compile cleanly. It's
> > a developer's release, at some point in future aimed to be stable.
> 
> Surely this is the reason of most peoples complaints today, all of us who
> are using Asterisk in real world, commercial environments get extremely
> frustrated when 'key' issues get fixed in the 'head' release, for example,
> recent fixes for IAX and SIP voice quality, and are not back ported to the
> stable/release/whatever version.
> 
> It leaves us in a very difficult position, as commercially we are placing
> our users at unnecessary risk by using the 'head' version to get a specific
> bug fix, but also giving them poor service if we stick with the 'broken'
> version.

I'm current;y in a similar position, so I feel some of this exact pain.

> Please can those responsible have some understanding of this, as a rule
> would it not make sense that all (or at least all major) 'fixes' go into
> both after being appropriately tested, and keep 'head' for the more
> 'bleeding edge' new features and more radical changes etc?

I think from watching the -cvs list, some of the patches can't be
brought backwards without also bringing back some of the major changes.

As version numbers are just arbitrary pointers at a point in source code
time, don't get too worried about the label. To make all those that are
currently making noise happy, maybe it should be put forth that current
stable has a version number and is abandoned. Then you place a new
feature freeze on -head and fork a new -head off and go from there. 

It will not address software quality, but it will make some people
happier to see version increments. Also it might get some of those who
wouldn't run a cvs version ever to install a more recent tagged release.
At this point it is easier to diagnose some of those problems. 

I might feel better about my pending upgrade to -head on a production
machine if I knew for sure that x% of the list was running it and had
experienced no trouble in their test environment where the value of x
was sufficiently large. As I know that isn't a true identifier of
quality or thoroughness of testing, I'll just have to add myself to the
x when I get there.
-- 
Steven Critchfield  <critch at basesys.com>