[asterisk-dev] AMI/ARI versioning

[Matt Fredrickson]

On Fri, Mar 31, 2017 at 10:37 AM, Corey Farrell <git at cfware.com> wrote:
> 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> 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
>>
>
> 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.

I'm ok with this approach.  We've discussed the past once or twice.
I'd prefer if X were the major version of Asterisk, but I'm willing to
compromise that it at least be some sort of number mapping scheme.  I
kind of hate that we have to make a number map at all, but I
understand that concern and potential confusion.

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA