[Asterisk-Dev] When do we change manager version?

[Steven Critchfield]

On Thu, 2006-01-05 at 22:42 +0200, Zoa wrote:
> How about asterisk checking what version we expect and act accordingly ?  :)
> Maybe thats too much too ask though...

While it would make the asterisk code a little more bloated having to
deal with many different versions of responses, I think it is better
than needing to get all the support apps into lock step with asterisk
manager changes. 

Maybe it is time to start manager v2 with the idea of negotiating an
acceptable version of the protocol and then proceeding. Maybe it might
also be nice to move the protocol out of the commands a bit and create
essentially a MVC to handle multiple representaions of the data. This
might allow for the handling of legacy V1 manager protocol without
having the underlying code stagnate. 

Of course I say this without any real knowledge of the underlying code
for the manager system. I haven't even used anything based on the
manager in over 2 years. 

> Julian Lyndon-Smith wrote:
> 
> > I would have manager interface v2 the default (with the option to run 
> > the old manager interface via a startup option). New / changes to 
> > events would only be added to the manager v2+, making it desirable to 
> > move to v2.
> >
> > Moving forwards, you can then add a version stamp to v2+ manager 
> > events,  as you can assume that applications would be taking note of 
> > the version number and acting accordingly.
> >
> > My 2p.
> >
> > Julian.
> >
> > Florian Overkamp wrote:
> >
> >> Hi,
> >>
> >> Olle E Johansson wrote:
> >>
> >>> Anyway, do you think we can change syntax *without* changing version 
> >>> number of manager or do you agree that we need to change version 
> >>> numbers and document differences in a README.managerversion?
> >>
> >>
> >> I'd say that when backward compatibility is broken the manager 
> >> version announcement should reflect that, so we can be sure of what's 
> >> happening. Lots of people depend on certain behaviour for their 
> >> applications, so they should at least be able to detect that things 
> >> will be funky from now on.
> >>
> >> I'd even appreciate a way to maintain backward compatible behaviour 
> >> for a certain period of time to support a migration path for all 
> >> dependant applications. Your idea of running a second manager module 
> >> (and a second manager port) with the new syntax is a _really 
> >> userfriendly_ approach.
> >>
> >> Florian
> >> _______________________________________________
> >> --Bandwidth and Colocation provided by Easynews.com --
> >>
> >> Asterisk-Dev mailing list
> >> To UNSUBSCRIBE or update options visit:
> >>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>
> >>
> >
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > Asterisk-Dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev