On 03/31/2017 10:47 AM, Kevin Harwell wrote:
On Thu, Mar 30, 2017 at 6:54 PM, Corey Farrell <g...@cfware.com
<mailto: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
<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.
--
_____________________________________________________________________
-- 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
