This is an easy thing to say, however it is not customer centric and is a huge burden on all app vendors, the impacts of which then trickle down to customers. I’ve seen a couple of replies along the lines of “just ship two versions”, with little to no commentary from Atlassian about why a vendor would not want to do that.
The sentiment being expressed is you will certainly need two versions of the app, however I’m sure there is nuance and workarounds that could be put in place by vendors to avoid this. The information about how to do this however is somewhat siloed, if possible I’ll try to document what we’re doing here at team ScriptRunner.
Personally if I have to spend a month engineering the app to be cross version compatible, I would gladly take that hit on productivity in the short term, because I have seen the business and customer impact of the alternative.
Customers on older platform versions have paid Atlassian (and us as the vendor) and rightfully expect to receive consistent updates, as long as their host application version is not end of life.
With the host application there is no expectation of new features without upgrading the major/minor version, however with apps there is more of an expectation of consistent updates. Some vendors make the choice to only fix bugs and security issues on older application versions, others opt to ship as much new functionality as is financially viable to all supported versions.
I accept that a major release is the only opportunity Atlassian has to properly introduce breaking changes, and have no issue with that in isolation. I do have an issue with statements that make it seem like forking your app codebase is a trivial endeavour, and that it does not f*ck the customer.
Atlassian’s job here is to clearly document all planned breaking changes, which has not yet happened, so app vendors can work with their teams to put together a backlog of work. The end goal being Platform 7 compatible on day 0, or as close to it as is possible.