[asterisk-users] Upgrade to Asterisk 1.4 - it's one year's old!

[David Boyd]

On Sat, 2007-12-15 at 10:51 -0600, Tilghman Lesher wrote:
> On Saturday 15 December 2007 10:02:23 Rob Hillis wrote:
> > One of the biggest barriers to upgrading are the number of little
> > "gotchas" in syntax changes that can make an upgrade from 1.2 to 1.4
> > quite painful.  After the pain I went through upgrading to 1.4, I've
> > always been recommending to people to think twice about upgrading if 1.2
> > does what they require.
> >
> > Many of the changes may have been seen as minor - one or two changes are
> > to be expected, but I ran into at least half a dozen - mostly variable
> > changes if I recall correctly - things such as deprecating CALLERIDNUM
> > in favour of CALLERID(num).  Some of the breakage was minor (e.g. loss
> > of caller ID processing) but some of them resulted in calls being
> > dropped in unpredictable places.
> >
> > All I can say is with 1.6, if a change is made that causes something
> > that worked in 1.4 not to work in 1.6, please think twice, three times
> > or four times before making the change, or making the change in such a
> > way that it won't break dialplan stuff from 1.4.
> 
> If anything broke from the transition from 1.2 to 1.4, it is because you were
> using something that was deprecated in 1.2.  What we had attempted to do
> in deprecation modes was to print the warning ONCE for each deprecated
> operation, per Asterisk startup.  I think that this was much too conservative.
> It is very easy to miss that deprecation warning, since it occurs so few
> times.  Of course, the opposite side is that we don't want deprecation
> warnings to fill up your logs, so there's a balancing act here.  But we could
> probably do with making the deprecation warnings a bit more prominent
> and print them multiple times (for example, every 10th usage).  That should
> make it more clear that there's something to change.
> 
> Of course, all of these deprecations should be covered in UPGRADE.txt, so
> please read that file every time you upgrade to a new version.  It will
> contain everything that has changed in a possibly incompatible way.  And if
> you find something that broke that wasn't in this file, please let us know, so
> we can revise that file.  We may not have gotten everything, but we do try.
> 

Hello Tilghman,


So if I read you correctly, all of the pain of the upgrade is due to
lack of effort on the participants part! 

This seems a whole lot like the attitude of proprietary vendors when
they don't want to support a feature that is outside the scope of what
they want  to maintain. I thought this was an open source project that
would allow participants to have a voice in what is or isn't included in
a new release. Even an non developing end user provides valuable benefit
to the project in QA and bug information to improve the project as a
whole. Most  (With exceptions) projects have a bit more interest in what
the user community wants or needs  in a  package. The attitude of this
project seems to be " If you want it code it yourself, however if it
something that doesn't map to the ideas of what Digium wants then it
will never make it into the official release. 

I don't understand why so much community support is placed into the
project considering that the typical end user is treated like a second
class citizen. 

So Digium, (I address the company since Tilghman now works for you) do
you have any plans to query the user community and determine what a
typical end user of the product needs? With the knowledge and skill that
exists in  your organization it would seem trivial to put something in
place to allow user feedback not only developer feedback for release
direction.

My 2 cents, ok 25 cents,
Dave