Ember release cycle
I’m not core team or anything so I can’t speak with any authority here but I think there are a few ideas in the ember release cycle that might be good to explain a little bit. When you said “For me Octane feels like it should have been Ember 4 release” I think that’s exactly opposite the intention behind the idea of Ember Editions. I don’t recall exactly when/where, maybe EmberConf, but when Tom and Yehuda were introducing the concept of editions they spoke about how there are periods of churn and new features, etc followed by periods of stability and polishing and consolidation. Ember has (for a while, at least since 2.x) taken the stance that a major release should only remove deprecated APIs, not add new features. A major release indicates that the library has undergone a transformation and not only added a bunch of cool new stuff but also shed baggage from preceding versions. A major version is entirely breaking changes in that sense.
The concept of editions (the first of which was Octane) was introduced to signal the other side of the churn/stability cycle, wherein a set of new features is landed (incrementally) and cohesively referred to as an Edition, while the framework starts to deprecate old APIs that have been replaced in anticipation of the next major release. That’s the stage we are in now, working towards the Ember 4.0 release after having landed Octane and steadily working on deprecating old/confusing/load-bearing gross APIs, and also fill API gaps for things that didn’t make it into the Octane edition proper.
So if it feels like there was a lot of churn recently, well, there was. That said there are a lot of things done to reduce churn during these periods for LTS apps. New features are, as a general rule, optional and can be adopted incrementally. We upgrade our app (and subapps and whatnot) at my company but it will take a LONG time for us to convert everything to Octane conventions, and there’s no reason to be in a huge rush. Our stance is “if you touch old code, refactor it” but otherwise we leave it alone. Tackling deprecations is most important but if you use deprecation workflow you can get through those incrementally too, and for the most part all the recent deprecations won’t be breaking (removed) until 4.0, so there’s plenty of time.
I want to give a big fat preface here that I’ve never maintained a long-lived React/Vue/etc app personally. I’ve mostly used them for shorter/smaller/academic exercises. That said I have good friends who do both, and I pay attention to the greater js ecosystem as much as I can, so I’m not just talking out of my butt here either… I think no matter where you go the story is going to be the same or far worse.
Making upgrades more bearable
- stick with convention, follow the Ember guides and lint rules and so on, follow the “happy path”, try to use good community endorsed patterns
- be very choosy about what addons and 3rd party libraries you let into your project, addons and 3rd party libs are some of the biggest upgrade headaches in my experience. So many are well worth it but you have to be careful to weigh the long term cost of every addon you adopt
- stick with LTS upgrades, don’t do big bang upgrades
- handle the changes and deprecation incrementally, don’t do massive sweeping changes, new features aren’t required, just encouraged so adopt them as you see fit
Also pay attention to the community and always feel free to reach out for help. Ember’s community is one of its strongest points in my opinion and there are so many great devs with similar experiences and lots of ideas and tips to offer.
All that said, it sounds like you’ve done some great work. I’m obviously biased but keep going, stick it out, make some adjustments to your process if you need, and enjoy the ride
EDIT: as far as addons go, Ember core team/framework couldn’t (and shouldn’t) make any rules about how third party addon authors maintain their code other than best practices and happy path tooling like ember-try. Unfortunately that means a lot of addons aren’t always going to be documented well or consistent in regards to which versions of Ember they are supposed to work with, though many of the popular ones set a good example in their READMEs and changelogs/release notes. What that really means is you have to be careful when updating your 3rd party stuff. If you have a robust test suite that you feel confident in a tool like greenkeeper or dependabot could be useful as they will open per-dependency PR branches to test with your app.