We’re planning to release Bahmni 0.89 in April, and we want to use TRUNK-425 to speed up our patient searches by leveraging Lucene. (Thanks @raff for shepherding this, and @adamg for doing a lot of the work!)
Therefore we would like to release Platform 2.1 sometime in March.
Historically the Platform has been released once a year, but we’ve been having discussions since the Singapore meeting about allowing motivated organizations to do more frequent releases, but perhaps to treat them as “non-LTS” releases or something like that. The Bahmni team is ready to be the guinea pigs for doing this the first time.
My request to others in the community is to help us do this. Particularly, please help us understand what expectations you have for having us do this mid-cycle release.
For example:
I expect that we’ll have a much shorter cycle of public UAT than for our “main” annual releases, but the Bahmni QA team will do a lot of testing via the Bahmni workflows.
I expect that the will not drop Platform 1.11 from the list of supported versions until Platform 2.2 gets released at the end of the year.
Otherwise I expect nobody is especially concerned about this “early” release, as long as our team puts in the effort to do it. (Though it will slightly increase the burden on folks who are merging PRs and backporting code, because now they’ll have to backport to 2.1.x, 2.0.x, 1.12.x, and 1.11.x, instead of the historical 3 release lines.)
Thoughts? Concerns? Encouragement?
(Also, does anyone have any work-in-progress I should be tracking, that they’d really like to get into an April release instead of an end-of-year release?)
Releasing earlier than later is step in the right direction!
Looking at the efforts that the Bahmni team has already put in the platform, and is willing to put in, it would be unfair to oppose this.
The increase in the burden of back porting to an extra release, is small in comparison to the benefits we are getting in doing this.
To be clear, we never intended to have one platform release per year; rather, we decided that we should never go more than a year between releases. This followed the saga of 1.10, where we went 18 months without a release.
We would have released every month or two if we could, but felt that “at least once per year” was a commitment we could safely make.
I’m also on board with releasing more often. What I want to make sure of though, is that we are mindful of the majority of implementations that cannot move this quickly. I have been disappointed by a bit by what has seemed like a blind adherence to our “support only the last 3 releases” policy, regardless of how quickly these releases have come in succession, how stable they are, how many backwards-incompatibilities they introduce, and how widely they are adopted.
I think (or maybe this is just my narrow, PIH-centric projection) that we can consider 1.6, 1.9, 1.11 to be LTS-style releases, given that they stood the test of time, with broad module support and extensive implementation usage. I think we should aim to more officially recognize releases like this, and to commit to supporting them for longer, when possible.
Can we accelerate a more official adoption of an LTS policy?
I’m fine with having a LTS policy but isn’t 1.6 way too old? It should harder to back port anything to 1.6 and 1.7 banches given the major changes in their project structure and later branches or master.
Sorry, I didn’t mean to imply that we should continue supporting 1.6 now. LTS means Long-term support, not forever-support. Ubuntu has a 5-year support policy. I don’t think we necessarily need to go that long, I just think we shouldn’t automatically drop support for a bunch of historical releases that are still actively used and that have huge module support just because we have resources to release the platform more often.
Releasing more often has a lot of benefits. But we should identify particular releases that we are shooting for on our roadmap as ones that will garner longer-term support, based on features included, stability, and other factors, commitment from implementations to upgrade to it, etc.
I would also love to hear about implementations which are on 1.6 in the sense of what has been the major blockers to moving to versions like 1.9
Is it modules they are depending on that do not have support for newer platform versions? Upgrade errors without support? Or something else beyond our countrol?
Such feedback will help us know how we should improve to make it easier for implementers to take advantage of newer releases.
I thought the main driver for less-frequent releases was that implementations typically don’t want to upgrade faster than this. (Since in Bahmni this process is more automated, and the range of configurations is less, people shouldn’t specifically care whether or not they’re doing a minor or maintenance upgrade of OpenMRS.)
This is the key dilemma:
We’ve always said “we support the last 3 releases.” Since we’ve fallen into the cadence of annual releases, that has meant “support for 3 years,” which seems fine to me. If that’s the case, maybe we should just make that our official statement.
The alternative would be if we denote only one release per year as “LTS (supported for 3 years)” with other releases supported for only 1 year.
So in this case 2.1.x would become a non-LTS line and 2.2.x would be the LTS one (unless there’s another non-LTS release before end-of-year). Then the support windows for these various versions would be
2.1.x until Mar 2018
2.0.x LTS until Aug 2019
1.12.x LTS until Jun 2019 (or maybe this is non-LTS and just until Jun 2017)
1.11.x LTS until Feb 2018
1.10.x LTS until Sep 2017
1.9.x is EOL already (should have been under LTS support until Jun 2015)
Note: this implies that after Mar 2018 we would backport bugfixes to 2.0.x but not to 2.1.x. (And we we might make a similar choice with 1.12.x.)
From the Bahmni side, we just want to be able to make quick releases more frequently, and we’re fine if this doesn’t imply they all get LTS. Our only request is that as an OpenMRS community we decide quickly how to approach this, so we can get a release out with the correct process in the coming month.
Regardless of how many past releases we choose to support, i do not see any gain we would make by discouraging more quick releases from a team like Bahmni that is not only making this proposal but also putting great efforts into the actual releases.
In the light of the responses so far received, everyone agrees with the more frequent releases.
The remaining bit of the puzzle is how many past releases should we support?
Supporting each release for at least 3 years, makes a lot of sense to me, and is a simpler formula to understand.
That’s true @dkayiwa. But let’s say that we end up doing quarterly releases. That’s 12 releases over a given 3 year period. I don’t know about you, but I think backporting (and testing) every bug fix to 12 historical releases would be prohibitive to any reasonable contributer. I think that would be a barrier to progress and would make developing for OpenMRS platform more painful and less fun.
So, although I think it could be a bit odd to have some code backported to, say, 1.11, and not to 1.12, I think the LTS support approach is one that can actually be implemented more easily.
One approach might be for us to think differently about LTS branches. Maybe that means we actually consider backporting features into minor releases within our current structure, for branches dubbed LTS. Or maybe it means that we create an entirely new set of branches (maybe with codenames) to represent our LTS release. These would happen predictably (every 2 years, say), and would would be allowed to cherry pick commits (including major features and data model updates) from other branches as appropriate, with the primary goal of maintaining backwards compatibility and supporting implementations with large installs and a low tolerance for major, breaking changes.
I’d love to keep discussing, maybe on a developer or design call. Either way, to get back to the point of the thread - I have no problem with releasing more often. That’s a good thing. We just need to adapt our processes a bit as a result.
In real life, since dealing with the big upgrade-to-Platform-2.x hump, Bahmni switched to Platform 2.0.x in December (requiring some maintenance releases) and we want to release Platform 2.1.x for a March/April Bahmni release. So Mike’s hypothetical scenario of a minor Platform release every quarter is very plausible.
To be clear:
Bahmni wants to help by releasing more quickly; this will also let us make more improvements directly to openmrs-core.
We can’t commit to supporting all of these releases for 3 years; we prefer to invest our time in upgrade scripts, etc, to make upgrading easier.
Like Mike, I think the LTS approach will make things easier for OpenMRS.
Wearing my Bahmni hat, I don’t think we care whether it’s “one LTS platform release per year” vs one of the new models Mike is suggesting. We just need guidance if this will affect how we do the 2.1.0 release.
@jthomas can we discuss on a design call? (I’m available tomorrow, but then on vacation for two weeks.)
The key point is that to support “quick non-LTS releases”, we should stop conflating “minor release of openmrs-core” with “release of the full Platform”.
Particularly, Bahmni needs to release something that’s part of the official OpenMRS main line, and that we can refer to by a released version number. But we’d like this to be as lightweight as possible to do, and we want this to be framed as “cutting edge” and/or less supported.
Thus we propose:
When a group like Bahmni wants to spend the effort, they can do a minor release of openmrs-core
this is not advertised as a release of “OpenMRS Platform”, just of openmrs-core
this is advertised as “cutting edge”, and has no specific support duration
there’s a release in maven, and a git release branch
this release need not include building a standalone or updating the bundled modules (but if we do eventually automate this, it can)
One Platform LTS release per year
doing this requires updating the bundled modules, the CIEL dictionary, releasing a standalong
doing this requires a longer end-user UAT window
any openmrs-core release branch included in a Platform LTS release is supported as LTS for 3 years
any module bundled in a Platform LTS release is supported for 3 years. (specifically, we’ll maintain backwards-compatibility of the module at least as far as the latest maintenance release of the openmrs-core release branch)
version number of the platform release corresponds to the openmrs-core version it’s based on
A side effect is that Platform LTS version numbers may skip, if non-LTS versions of OpenMRS core were released in between. In practice, in the current scenario we’d expect to have:
OpenMRS Platform 2.0 LTS (released 2016, supported for 3 years)
openmrs-core 2.1 (release March 2017, no guarantee of support beyond release of 2.2)
openmrs-core 2.2 (release in July 2017, no guarantee of support beyond release of 2.3)
OpenMRS Platform 2.3 LTS (release in Q4 2017, supported for 3 years)
Should we run Reference Application 2.6 on Platform 2.1? Or in other words should we be always using LTS releases for RA or is it okay to use non-LTS versions?
Also we should probably include -LTS qualifier in versions released to maven repo e.g. 2.0-LTS to easily distinguish them…
With the level of dev effort that has gone into the reference application
over the last couple years, I would personally say it should remain based
on an LTS platform release.
But it would be better if the reference application were driving new
OpenMRS core functionality more, and that was my original vision.
If we are able to sustain a higher level of dev involvement in the
reference application then I could see us basing it on the cutting edge versions. (But
that could imply a longer support requirement.)
I think using LTS platform releases for RA will slow us down. We should aim at improving further our testing for RA and use the cutting edge versions of platform. In fact RA releases are not LTS as none of modules included in RA are.
The increase in the burden of back porting to an extra release, is small in comparison to the benefits we are getting in doing this.