[Asterisk-Dev] removing depreciated code?

Steven critch at basesys.com
Sat Sep 24 07:38:56 MST 2005


On Sat, 2005-09-24 at 11:12 +0200, Roy Sigurd Karlsbakk wrote:
> > I would point out that removal of those portions would cause us to
> > increment the major version to stick with rational version number
> > schemes. Removal of the functions, especially the +101 jumps would  
> > be a
> > non-backwards compatible change. Non-backward compatible changes  
> > should
> > be met with major version number increases.
> >
> > We all know the next release is going to be 1.2. Therefore we  
> > should be
> > able to expect backward compatibility of the config files.
> >
> > A big benefit of 1.2 is that it can be used as a transition phase of,
> > upgrade to this release, then upgrade your configs and the next  
> > upgrade
> > will be just as painless.
> >
> 
> Are you sure this is a good thing? Having the backward compatibility  
> is one thing, but then if something doesn't work, the general answer  
> from the Asterisk Community is bound to be "that is obsoleted by  
> xxx". So then, instead of keeping all the old trash, kick it out and  
> force people to rewrite their dialplan; it won't take that long anyway.
> 
> Backward compatibility is overrated

Try telling that to a person who makes the upgrade and finds out they
have to re-tweak the ENTIRE dialplan to make it behave the way they had
it before.  I would much rather upgrade sections at a time where I can
fully test those sections before moving on. 

Remember the current use of the word stable? It should be able to be
applied to the dialplan as well. If I can keep most of my dialplan
stable(unchanged) and work on a section at a time, I have reduced the
number of potential errors introduced at any specific time.

-- 
Steven Critchfield
critch at basesys.com
KI4KTY




More information about the asterisk-dev mailing list