Thanks @darius. As I try to get my head around our evolving release policy, I’d like to make sure we aren’t mistakenly conflating ideas.
Are we assuming all releases of the Platform and Reference Application being longterm support (LTS) releases?
We appear to be taking this approach:
WARs are released as non-LTS Core. Platform & RefApp are all LTS.
Do we want this instead?
Releases include as Core (WAR), Platform, and RefApp. Core is, by definition, non-LTS. Platform & RefApp are either LTS or non-LTS releases based on need.
[quote=“burke, post:1, topic:11248”]
Releases include as Core (WAR), Platform, and RefApp. Core is, by definition, non-LTS. Platform & RefApp are either LTS or non-LTS releases based on need.
[/quote] @burke That seems to make sense.
To add more to the confusion, I am assuming that the LTS versions for platform and RefApp are not the same length … Assuming 3 versions (I beg to be corrected) means that Platform is 3 years and Ref App 18 months - assuming the release schedules are on track.
I only made small updates to the wiki page that was already there, to mention the idea of non-LTS releases (with a minimal amount of effort so I could get something on the page). I agree that the page does not express our current thinking.
I disagree with one point: RefApp releases are not LTS as such (and cannot be).
Here’s what I think our current thinking is:
Core and Platform
we will do one Platform LTS release per year
we may do additional non-LTS Platform releases in the year.
we may do core-only releases, that follow the same numbering as the Platform, but don’t include all the components. These are never LTS, and are only a convenience done for developer convenience, targeted at those who are committed to always be running the cutting edge release.
(Burke does not like this much. If we are able to simplify our Platform release process enough we may discontinue the idea of “core-only” releases.)
we support three LTS Platform release lines at a time. Currently these are 2.0.x, 1.12.x, 1.11.x.
(I suggest we change this to state that all LTS Platform releases are supported for 3 years.)
we haven’t explicitly said how long non-LTS releases are supported. I suggest we say they are only supported until the next Platform or Core release. (In other words, if you take one of these, you’re committed to move to the subsequent release as soon as it’s out.)
Reference Application
We release the Reference Application twice a year
In between we do not do maintenance RefApp releases, except in the case of critical security issues.
We have only does this once, with RefApp 2.3.1.
With every RefApp release, we trigger the release of all included modules that have new code committed to them. (Individual modules are often released outside of the RefApp release cycle also, at the discretion of their owners/contributors.)
But since there are no RefApp maintenance releases, if someone wants “RefApp version X + bugfixes” they must manually upgrade openmrs-core and modules (and we don’t actually test specific configurations).
We have never explicitly said that including a module in the RefApp means it will continue to be supported for a specific period of time.
in practice we have never removed a module from the refapp unless its functionality was folded into another module.
(I do hope that someday we can remove the provider management module from the RefApp, by moving some of its functionality into openmrs-core.)
So, although it sounds nice to have RefApp maintenance releases, we’re nowhere near being able to do this. In practice it would be an unreasonable ask of module authors. Therefore, Reference Application releases do not promise any explicit support duration, and are not LTS as such.
(I vaguely remember @ssmusoke having suggested a feasible way to make them happen, but I don’t remember what it was…)