Switch to semver, release 1.0.0

[saghul]

So, about time for 1.0.0, don't you think? :-)

I spotted the following change in the last patch release: https://github.com/versatica/JsSIP/commit/9a8537bab1e8716ec75f955d52b1fd0b296b4fab While seemingly inocuous, some people could be relying on that ordering and might upgrade without giving it much thought. If we were using semver, this would have warranted a major (or at least minor) version bump.

[ibc]

While seemingly inocuous, some people could be relying on that ordering

That ordering is a bug, sure ;)

[ibc]

Honestly I do not like semver, it is too much "aggressive" IMHO. If each incompatible API change should trigger a new MAYOR number then JsSIP would already 25.X.X.

[saghul]

If each incompatible API change should trigger a new MAYOR number then JsSIP would already 25.X.X.

So? Are version numbers costing us money now :-)

If not semver, what's the policy for bumping the version to 0.8.0? Or 1.0 for that matter?

Semver is not perfect, but IMHO it does something right: indicate what to expect from a version given the previous one.

[ibc]

So? Are version numbers costing us money now :-)

They are limited resources, aren't they?

If not semver, what's the policy for bumping the version to 0.8.0? Or 1.0 for that matter?

Current policy: http://jssip.net/documentation/versions_and_compatibility/

• Two JsSIP versions with same MAJOR and MINOR numbers are API compatible.
• A version with same MAJOR and MINOR numbers but a greater TINY number just includes internal improvements or bug fixes.
• A version with different MAYOR or MINOR number includes new features and/or non backward compatible API changes.

Right, it makes no sense :cow:

Semver is not perfect, but IMHO it does something right: indicate what to expect from a version given the previous one.

LGTM. Let's move to 1.0.0 once we close some pending issues. @jmillan?

[jmillan]

Hi,

I've started some changes on the Transport layer which I'd like to introduce in 1.0. I think that would be a good moment for the upgrade.

I agree on the fact that changing behaviour should be indicated, and versioning is the right way to do it. Also, users should read the Changelog before upgrading.

BTW, it will be a good chance to take a look at semver!

[saghul]

Hell yeah, lets do this!

[saghul]

Gentle reminder :-)

[ibc]

While I agree, I cannot figure out the exact moment to bump to 1.0.0 given that jumping from 0.7.X to 1.0.0 without real API changes seems a bit exotic IMHO, isn't it?

[saghul]

No, it means you are committing to keeping that API, which is a good thing! If the API is later broken, v2, then v3, and so on! I have a discount coupon for version numbers, in case you need it :trollface:

[ibc]

What would happen when all the possible SEMVER major numbers are exhausted?

[saghul]

The world would implode and we'd be jobless anyway, so YOLO!

[ibc]

@jmillan thoughts?

[jmillan]

I'm Ok with SEMVER guys 👍

[saghul]

Awesome, please do the honors then :-)

[ibc]

Fine, @jmillan I suggest fixing the new SDP event, merging into master and then let's 1.0.0.

[jmillan]

👍 Okey

[jmillan]

I've just realised that RTCSession sending event is a decaffeinated version of the new sdp event. The former was created to able to change the SDP as well, but only applied to initial outgoing request.

Since we are moving to 1.0.0, which allows API changes, I'll remove this event in favour of the new sdp one.

[saghul]

:+1:

[ibc]

Done

[saghul]

🎉 🎉 🎉 🍰 🍰 🍰 ✨ ✨ ✨