[asterisk-dev] AMI/ARI versioning

[Corey Farrell]

On 03/31/2017 10:47 AM, Kevin Harwell wrote:
>
>
> On Thu, Mar 30, 2017 at 6:54 PM, Corey Farrell <git at cfware.com 
> <mailto:git at cfware.com>> wrote:
>
>     On 03/30/2017 07:14 PM, Kevin Harwell wrote:
>     I think it's worth referencing a previous discussion on this [1].
>
>
> Yes, thank you! I looked for this and for some reason my searches 
> turned up nothing.
>
>     I agree with Mark's idea that having the ARI/AMI major version
>     tied to the Asterisk branch could lead to confusion, lead people
>     to believe that ARI 14.3.0 == Asterisk 14.3.0.
>
>
> Yeah I could see that causing confusion.
>
>
>     [1]
>     http://lists.digium.com/pipermail/asterisk-dev/2016-November/075964.html
>     <http://lists.digium.com/pipermail/asterisk-dev/2016-November/075964.html>
>
>
> Mark Michelson wrote:
>
>     2) Bump the major version of ARI for each major release of
>     Asterisk. We
>     won't retroactively apply this to the upgrade from Asterisk 12 to
>     Asterisk 13. So Asterisk 13 will have ARI versions 1.X.Y, Asterisk 14
>     will have ARI versions 2.X.Y, and Asterisk 15 will end up with
>     Asterisk 3.X.Y
>
>
> I'm assuming the other numbers would just be reset here? For instance 
> when Asterisk 15 is released it would it become 3.0.0?
>
> I think either way we do it the versioning ends up being somewhat 
> localized to the associated branch and the major number can't change 
> once set on a branch.

Yes each new major version of Asterisk would start with AMI and ARI 
version X.0.0.  Once Asterisk 15 is released with ARI/3.0.0 we can't 
bump Asterisk 14 to also use ARI/3.x.x.  Although the versions are 
localized to the associated branch I think we should enforce that an 
older branch of Asterisk always has a lower major version for ARI/AMI.

With version X.Y.Z, I think this should represent:
X: architecture / Asterisk branch.  On bump of X all bets are off. X is 
associated to a specific major version of Asterisk but not an equal number.
Y: breaking change to existing features, but overall architecture in 
tact.  Might break/remove a function or event, ignore a parameter, add a 
new required parameter, etc.
Z: non-breaking change/addition: added optional parameter, new attribute 
in response, new function/event (including from any new module).

So an app written for 3.0.0 should work unmodified against 3.0.1, but 
may require tweaks to work with 3.1.0.  An app written for 3.0.1 might 
work with 3.0.0, but not guaranteed if the app uses features added to 3.0.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170331/065fe2de/attachment.html>