Re: Rename ChannelUserevent to Userevent in ARI?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sun, Apr 20, 2014 at 11:21 AM, Leif Madsen
<lmadsen@xxxxxxxxxxxxxxxxxx> wrote:
> I wholeheartedly agree with Dan and Paul here. Asterisk 12 should be
> considered a development release that can change within minor versions in
> order to be as feature and API complete as possible for the next LTS.
> If this isn't the intention of the standard releases then my understanding
> of the discussions around them at AstriDevCon was mistaken.

To clarify: my issue is with renaming the event, and only with that.

While Asterisk 12 is a Standard release, that doesn't change the fact
that ARI was released in this version - and this is still a released
version of Asterisk. The guidelines for what can be proposed for a
change in this version of Asterisk are up on the wiki [1] - and while
those guidelines are fairly loose and do not explicitly say "no
breaking changes", it isn't a free for all. Disregarding Asterisk 12,
in any version of Asterisk - future or released - we shouldn't
introduce a breaking change on a whim.

To compound this, ARI follows semantic versioning [2]. A backwards
incompatible change would mean that we would bump ARI to 2.0.0. While
I agree that the event name was chosen poorly, changing the name of an
event mid-stream is pedantic. It isn't strictly necessary. If we're
going to bump something to 2.0.0, I'd rather it be for a much more
sweeping and important reason than "I don't like the name of this

Let's try to come up with another approach here, one that doesn't
require a backwards incompatible change.


Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: &

asterisk-app-dev mailing list

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux