I think there is some confusion here. I’m not sure where we stated that Ionic 3 would be our last release. I wrote a blog post when we released Ionic 3 about our switch to Semantic versioning and that we would continue to work on improving Ionic: https://blog.ionicframework.com/ionic-3-0-has-arrived/
When we decided to switch to Semantic versioning we made the decision that we would iterate major version numbers quickly if any breaking changes were introduced. So when we are jumping from Ionic 3 to Ionic 4 it is because there will be breaking changes (mainly caused by the internal refactor which will in turn speed up boot/load times) but it isn’t as breaking as the change from Ionic 1 to Ionic 2.
We did recently announce that we wouldn’t be releasing any more 3.x versions, unless they are critical security / bug fixes. That may be where the confusion lies. We are in the process of writing an upgrade guide to Ionic Angular 4 to make it easier to update your apps, and we’ll have an alpha out soon of v4 for some initial testing.
Thanks for taking the time to update everyone again on the roadmap!
As an ionic dev I’d like to backup the claim that updating my app from ionic 2 to ionic 3 was not very difficult at all (mostly just bulk find and replace) and I look forward to all of the benefits that the change to ionic angular 4 will provide.
Ionic should start doing LTS versions like Node. Every big rewrite might seem like ‘this is the last time’, but it will probably never be. You need to keep innovating and making ‘breaking changes’ or the fun ‘another rewrite from scratch’ wherever you want to for the exciting future, but provide a stable branch which will be maintained long term for any compatibility fixes etc… (without any breaking changes).
Ionic3 should not get only security fixes. Only ‘after’ v4 stable release, v3 should enter a 1-2 year LTS period with chrome/safari/edge/ios/android/windows/mac/cordova/electron/capacitor related fixes so that existing projects can continue to exist, in peace.
It is unfair to claim ‘security fixes only for v3’ even before v4 has had an alpha release. This is not ‘only’ a breaking change in API like v2 to v3. You are doing a complete rewrite (with API mostly same).
Most projects that are larger than 1 week hack/demo etc… use ionic components in complicated ways. Even if you plan to keep v4 migration ‘simple’ things are going to break all over the place because the underlying changes in components will change how the components interact, and all customizations etc will need to be adjusted/redone. It will need at least a few weeks/months of testing and debugging across entire projects, some where original developers have now left the teams. It is not going to be as simple as the syntax changes in https://github.com/ionic-team/ionic/blob/master/BREAKING.md
I think this is a really good idea. I’ve had a lot of fun with beta versions of both Ionic and Stencil. But to publish, not just learn, I would prefer something that is completely unsurprising.
LTS would be great and I think that your writeup about the complex interactions between components is true and well articulated - especially the point that the new release will be a near complete re-write with an almost identical API.
The problem is that the Ionic development team has limited resources and is just barely turning a profit (based off of statements I’ve seen them make publicly). They’re choosing how to best allocate their development time and they’ve decided to move forward quickly with ambitious projects like ionic-4 instead of spending time with maintenance tasks and LTS releases.
Ionic is still a fairly small project with limited resources compared to something like Node, with a large development community and foundation for funding. As Ionic grows there is a good chance that an LTS release will be possible in the future - but part of the downside of being a small community at the present moment means that you’ll have to spend time updating once a year when a major release comes around.
LTS will still mean that projects will need to catch up to latest, only that they will be able to do it at their own pace. Or decide to skip every other version safely, if its best for them.
I would love to do this ‘chasing the latest’ for my side projects etc… or where my team would get to choose what they want to do next. Its fun to work with the latest and greatest, lot to learn and explore and lot to improve in user experience, etc… But is it really an option for a production project with limited budget, fixed scope, tight deadline, and multiple layers of decision makers?
Its not ‘just one’ breaking change like apple adding the notch, or one cordova plugin changing behaviour or API. Ionic components are spread across all the UI, everywhere, every screen, every feature. Everything in a project will need to get refreshed and fixed and retested, even parts of code that no one had to look at in a year, which were written by people who had switched jobs long ago. Or features which were barely compeleted weeks ago, and will now need to be pried open and patched up and certified by testing again. Thousands of lines of code.
Try convincing any client that they need to pay for next 1-2 months so that we can catch-up with the framework that their project depends on, and it will lead to more bugs that will need to be fixed over time, and that those new planned features will have to wait, etc… And that they need to do it ‘now’ - because who knows what all will break with v3 when new iOS and Android releases are out again in September.
Or imagine a startup still evaluating if they have a worthy product or not, getting sidetracked to catchup with framework changes. Redoing things they already did, before its clear if they are even on the right track or not.
LTS still means this will need to be done, but sometime in next 18-24 months, whenever the project’s release cycle has breathing room, which can be planned. Or that they can choose to not decide for next 12 months and safely wait to evaluate project’s viability etc and focus on more pressing user demands - instead of the framework’s demands.
Ionic team is responsible enough to maintain compatibility fixes etc. They even updated Ionic1 for the iPhone notch:
They already plan to keep making any critical fixes etc needed for v3. Putting a LTS label and timeline will make it easier to plan and decide, or to skip a cycle, instead of people running around like headless chickens wondering “what to do” everytime any of these nice guys break something: chrome/safari/edge/ios/android/windows/mac/cordova/electron, and merge the pull requests when someone from the community steps up.
v4 is not the first non backward compatible release, and its not the last. LTS can solve both the the need for fast innovation and the long term stability.
Ionic will forever be maintaining only two versions at a time, and they won’t need to be apologetic about breaking changes. Developers won’t be stuck justifying why Ionic is still a great choice, contract teams won’t have to put unpaid hours in framework upgrades, and the project managers will have the visibility needed to plan - or skip - a framework upgrade depending on project needs.
@brandyshea Not only are you ignoring the open issues, but you’re blindly closing all of the open issues. Why is no one at Ionic checking these against the latest code before closing them? Your users invested time in reporting these issues and instead of verifying that they have been corrected, you have just closed hundreds of open issues with no valid response other than “check it against the latest code and submit a new issue if it’s still a problem”.
This is bullshit.
How can you expect your users to put the effort into documenting your problems if you can’t the the effort into reviewing them.
These comment are unnecessary and very unprofessional. Locking this thread.
With regards to closing issues/pull requests, closing them is the only valid option. Since the v4 codebase is much different than v3, issues are either not applicable anymore or have been fixed. If you are still seeing issues with the new code base, please open a new issue.
