[Asterisk-Dev] Time to lock down v1.1?
Fran Boon
flavour at partyvibe.com
Fri May 28 12:54:14 MST 2004
On Fri, 2004-05-28 at 19:33, Steven Critchfield wrote:
> 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.
Very true
> 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.
I would second that notion - let's get 1.0 released so that we can move
on from it asap.
There have been a significant number of bugfixes since 0.9.0 (e.g. IAX
timestamps) so at least a 0.9.x release seems due
> 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.
This is the reason why: packagers rarely package CVS releases.
Most users prefer packages.
Personally this is the first project I've got into where I've had to get
really dirty with CVS...previously there have only been short periods
where I've had to run a CVS snapshot for a very specific new feature &
then it was back to a formal release...
> 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.
Personally I'm very happy with HEAD - updates only break it
occasionally.
However, my system is fairly simple right now...
F
More information about the asterisk-dev
mailing list