As many of you know, Ionic Framework has undergone some internal updates and enhancements that we’re all pretty excited about. The net of these updates is that they will result in much faster startup times, smaller file sizes, and an updated API centered around web-standards. Ionic v4 (the version we’re working on) is currently undergoing some heavy alpha testing, and soon we’ll be releasing the beta versions. But along with these updates, we’d also like to be very transparent about our upcoming plans for scheduled releases, and Ionic’s Long Term Support (LTS).
We’d also like to better plan out how features will be added into the core project. Community feedback is a large part of our development cycle, and there’s no shortage of great ideas we’d absolutely love to include. The challenge is deciding which great idea we should work on today, and as developers I’m sure you understand the feeling. The Ionic community is massive, so it’s often difficult to judge which idea is best for everyone. But first, let’s chat about our versioning.
Prior to the Ionic team going heads down on v4, we were releasing Ionic updates about every two weeks. Since the early days of Ionic we’ve toyed with many different schedules, but we think a two-week release schedule worked best for our team and the community.
However, past releases weren’t very clear about “what” was going to be in the next release. To fix this, we’ll be able to better communicate by staying strict to Semantic Versioning. Both Ionic v2 and v3 followed Semantic Versioning, and version numbers bumped up quickly. But we realized some members of the community saw this as “Ionic moves too quickly”, which I’d like to better explain. To quote semver:
Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
When we roll out the next major release, it will restart at 4.0.0. Additionally, we’ll start to use the
ionic npm organization for each of the packages, which means the
ionic-angular import will become
Not only is Ionic using semver so apps can get a better sense of what changes to expect (breaking or non-breaking), but our goal is to better plan out our releases in a predictable manner. Here’s how:
A patch release is the last number in the version which basically means “we fixed some bugs, but Ionic has the exact same API, and exact same features”. When a new patch release comes out, our goal is that developers can safely update without any worry of breaking changes, or new bugs introduced from new features. Our goal is for a patch release to go out every two-weeks. Additionally, every release will continue to be published with a detailed Changelog describing what has been fixed.
With new features comes new code. Heavily tested code we’re confident in, but new code nonetheless. With new code comes the potential for new issues. For this reason, any new feature will always get a minor release by bumping up the middle number. To ensure patch releases can fix existing code without introducing new issues from the new features, bug fixes will always get their own patch release prior to any minor release. Minor releases will always have an accompanying Request for Feedback issue to help discuss the feature with community, and plan the release. The exact dates of minor releases depends on the feature being developed.
Major Release Heads-up
A major release means there is a breaking change. Like minor releases there will be a Request for Feedback issue, but also numerous release candidates so we can get feedback more quickly. One feature we’re excited with v4 is a migration tool which helps pinpoint any code which needs to be updated. This is something we plan on keeping up between versions of Ionic starting at v3 and above. This also includes backwards compatible APIs when possible.
With a heads-up we’ll be able to outline what is changing, and why. Additionally, we’ll be able to start including backward compatible updates prior to the release. But most importantly, we want to help developers easily transition to updated versions of Ionic for better performance, new features and improved developer experience.
I’d also like to point out that the transition from Ionic v1 to v2 was a massive one, largely because the underlying client-side framework was completely overhauled. We know how frustrating that upgrade was for many people. Now that Ionic Framework is based on top of web-standards, which are baked into the browser instead of a dependence on third-party code, moving forward we do not foresee major releases like we did in the past. As for framework change, Angular has also adopted semantic versioning, providing a clear path for when changes will be made, and if those changes will be breaking.
Long Term Support (LTS)
Ionic has been maturing for a few years now, and with our move to web standards like Web Components, we’re more confident than ever with the long term stability of the API we’ve developed, and for the millions of apps already using it. Starting with 4.0.0, we’ll be providing Long Term Support (LTS) with a defined support schedule for the Ionic community.
With LTS we’ll be able to provide developers and organizations additional confidence and stability for the apps they’re developing. The details deserve their own blog post(s), and to be honest we are still working through the specifics, but we’re modeling Ionic’s LTS support off of industry standards like Node.js. We are more than thrilled to offer this for the community, and we also plan to offer Extended LTS and other related benefits for our Ionic Enterprise customers (who should reach out to our Customer Success team for more details).
We’re fast approaching the beta release of v4, and we can’t thank the community enough for all the help. Our next big step is to finish up documentation site refresh (we think you’re gonna love it, because we do). The docs will include usage examples in not only Angular, but other frameworks too, or no framework at all!
Currently we’re closing out the remaining alpha issues of
@ionic/angular, and with the release of v4 we’ll next shift our focus to improved desktop support, and official React and Vuejs support. Stay tuned!