On Fri, Mar 31, 2017 at 10:37 AM, Corey Farrell <g...@cfware.com> wrote: > On 03/31/2017 10:47 AM, Kevin Harwell wrote: > > > > On Thu, Mar 30, 2017 at 6:54 PM, Corey Farrell <g...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
