Bahmni team wants to release Platform 2.1 (soon!)

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?

Thanks, Mike

1 Like

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.

Mike

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.)

@mseaton and others, does this seem right?

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. :slight_smile:

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.

Mike

1 Like

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.)

1 Like

Of course. Design time is currently open so the call is yours. Who all would you like to see on it?

@jthomas, it would be nice to invite everyone who has commented on this thread. (Burke too, but I know he’s on service so I guess unavailable.)

-Darius (by phone)

We are discussing this on the design forum now.

We had a very interesting discussion, with notes at http://notes.openmrs.org/2017-03-01-Design-Forum

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)

@burke and others, what do you think?

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…

1 Like

Good question!

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.)

What do you think @raff?

-Darius (by phone)

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.

If we do things like I said above, for example:

openmrs-core 2.1 (release March 2017, no guarantee of support beyond release of 2.2)

…then I would be uncomfortable basing RA releases on this. So this would mean we’d need to promise more support than I was thinking, right?

Also, in that model I’ve said we’re only releasing openmrs-core, not a full platform release, so we’d end up with RA releases without a true corresponding platform release.

These would seem like problem, right?

Well looking at the RA release schedule we would release RA based on LTS at least once a year and thrice a year based on non-LTS so an implementer would have a choice based on a planned upgrade scheduled.

Anyway, to keep things simple let’s just say RA is always based on LTS. We can revisit that, if we actually want to use some feature in RA from a non-LTS release. It’s not the case right now and there are other options to go around it, which can be considered e.g. enabling a feature optionally.

Is it possible to simplify the release process for Platform? Something like this for a non-LTS version of the Platform:

  • Run script that makes a maj.min.x branch and creates tag
  • Update openmrs-platform to use openmrs-core maj.min and tag it as maj.min
  • Maven package+release Platform
  • Go to wiki and create a new page using “Platform Non-TLS Release template” that automatically embeds a list of tickets for the release, add a sentence or two summarizing the purpose of the non-TLS release and save the page.

Do we anticipate that these non-TLS “core” releases might not actually work for the platform (e.g., OpenMRS Core 2.1 comes out and not all the platform modules will run against it, so a Platform release isn’t possible until the module(s) have been refactored to work with core changes)?

If we aren’t packaging & release core with platform modules, then I agree we shouldn’t label it as a “Platform” release. We’ll need to update the wiki to give some explanation of what this “OpenMRS Core” thing is. But, I’d rather make it easier to package up & release a non-LTS version of the Platform than finding a way to avoid releasing the platform. Automating packaging & release of non-TLS versions of the Platform would not only make things easier to understand (avoid adding a new “Core” beast to our road map + skipping version numbers in the Platform), but also improve LTS releases (which would benefit from the automation).

In this specific case we are adding obs.status and obs.interpretation, but since Bahmni doesn’t use the FHIR module we will not make changes to the FHIR module to support that.

(We do need the REST module to support these new changes, so we will take care of that, and release a new REST module version.)

In other words, doing a core-only release is significantly less work for the devs who want to do it, versus a full platform release, even if we script the platform release process to make it easier. (We should do that anyway.)

FYI I have released openmrs-core 2.1.0.

I updated our OpenMRS Release Policy wiki page to mention the idea of non-LTS dev-targeted releases, but what I wrote was pretty anemic (like the rest of that page).

In the next few days I intend to release the REST webservices module, and also write a more verbose wiki page about what non-LTS means.