[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