Is Ionic using Semantic versioning?

I’ve seen the 3.5 coming out and just wondering if ionic is using Semantic versioning as described in ?


I think they try to.
The URL changes in 3.5 could probably be considered breaking/incompatible for some usecases though.

indeed… should it be 4 instead ? or should they wait until 4 before breaking apps that rely on URLs ?

If you are very strict on the definition of SemVer and are very strict on its application, then you could argue that this should not have been in a minor update. But you can also argue in the opposite direction with a few dozens points (“not core funtionality”, “there are probably workarounds”, bla bla). Maybe the devs just weren’t aware or didn’t fully consider the consequences for all use cases (my guess).

If you feel unhappy about the way this was handled best create an issue at A good description of the problems go a long way.

Otherwise: It’s how it is now, don’t upgrade to 3.5 for now or live with the changes.

I’ve thought that it was the whole point of it…

Software and especially API definitions (what SemVer actually is about) are always subject to interpretation. Absolute strictness could only be achieved if the software/API was described with a definition file or code itself and the verions numbers then being decided based on that. This works for REST API endpoints described in Swagger maybe, but not for something like Ionic. So it becomes a question of interpretation again.

Again, I probably agree that changing the URLs is kind of changing the public API of Ionic projects in the browser, so this maybe shouldn’t be in a minor update. But also again, mistakes happen or things interpreted differently, a Github issue is the correct place to give that feedback (to make sure it reaches the developer - I am just a random guy on the community forum :wink: ).

We use semantic versioning for the framework, following this pattern

Major: Major changes include breaking changes that are not backwards compatible. That is, code you have written before needs to be updated.

Minor: Changes and features are added, but it doesn’t break an app.

Patch: Bug fixes that aren’t breaking

Since we’ve only done one MAJOR release since 2.0, we’ll use that as an example
We released 3.0 with a bunch of new features, internal changes, as well as depenedcy updates that were not backwards compatible. For instance, we had removed our older grid, and replaced that with our newer grid setup. That alone would make the jump to 3.0 valid.

We’ve had several 3.x releases that include but fixes, internal changes and dep updates that ARE backwards compatible. Since the code users write didn’t have to change between 3.1,3.2, 3.3 and 3.4, these are all consider minor releases.

And in between there we’ve had a few patch releases were some small bug snuck in, and we were able to fix them.

As for the url changes in 3.5, we dont consider this a breaking change, as it was backwards compatible. As in, the same IonicPage setup could work in 3.4 and 3.5.

So, yes we are following semver very closely


IMO version 3.5 introduced this breaking change

1 Like

I agree with you…
imagine an app that let users share URLS, so users may have post them in blogs etc… if the app updates to 3.5, it would break all those blogs, bookmarks etc… so it keeps the app locked to 3.4.2 which means that it wont get any bug fixing neither…