[asterisk-dev] Reintroduce deprecated applications

[Tilghman Lesher]

On Monday 12 May 2008 19:13:18 John Lange wrote:
> I don't have any particular strong feelings one way or the other on the
> old applications other than to say that everyone likes a simple upgrade
> path so keeping backwards compatibility is always nice.
>
> My only question mark would be, if the applications are worth keeping,
> aren't they worth improving? Why not accept patches?

We want people to move towards better ways of doing things.  So any new
features should be introduced in a way that is compatible with the future
direction.  We're keeping the applications around due to community feedback,
not because we think it's the best way to perform those tasks.  And holding
the line on new features is a good way to encourage people to slowly make the
transition.  Deprecating the applications was actually supposed to perform the
same purpose:  to encourage people to move to the new methods.  However, that
did not seem to work, given how many complaints we've received over their
subsequent removal.

I think it's a good compromise position, actually.

> It is completely reasonable to take the position that Digium is not
> going to expend resources working on old applications because every
> contributor in an opensource application has the "right" to decide whats
> worth working on and that includes Digium. And by the same logic,
> contributors who want to improve applications should be allowed, no?

Contributors who want to improve applications are always welcome, although
we will try to influence them towards the recommended way of doing things.
This is actually not all that different from how things are done now:  code
which does not meet the coding guidelines is rejected, and the contributor has
a chance to revise the code until it meets with those guidelines.

> Another option might be to move them to a separate package along the
> lines of asterisk-addons.

That was actually my original proposal, and it morphed into permitting the
applications to exist in the core, instead, as it's easier for the user not to
have to remember to install a separate package on each upgrade.

-- 
Tilghman