Bahmni minor releases

Hi @vinay, @bharatak and Bahmni team,

A while ago I set myself up to watch for new releases on bintray, so I get alerts like this whenever a new Bahmni version is uploaded:

bahmni has just released version 0.81-348 of the package bahmni-installer! Grab it from Bintray now:

I’m curious as to whether there is any way to track what has changed in these minor releases. Are they tagged in github? Are all projects tagged with the same version numbers? Or are there tags in Mingle that would provide some visibility into this? Basically I’m trying to understand how to determine if it is worth upgrading to the next minor version at any given point in time and what sort of regression testing we might do as a result.

Thanks, Mike

One way to know what went into a release is to refer to the Release notes.

We haven’t yet put up instructions for the community to move over to V0.81, since there are some issues with the install with demo data. Once they are done, I will update install instructions for the community, and post an announcement on OpenMRS Talk.

There should be a way to know this from Mingle too – at story/feature level.

@mseaton We branch every release of Bahmni. 0.81 version of the bahmniapps is this and bahmni-core is this. We generally do not tag the releases. As @gsluthra pointed out, release notes is the right place to determine the features of the release.

The projects like OpenELIS, openerp-connect, bahmni-emr are always all at the same version of the release. We branch all these projects while kicking-off a release. The mingle boards are configured per release and you can navigate it through the dashboard here.

Following up on Mike’s question, in bintray there are two versions of 0.81 bahmni-web listed 0.81-358 and 0.81-369. Is this non-standard, and, generally, there will only be one entry per release?

If not, would it be possible to tag within a specific release branch the point when, say “-385” and “-369”, were cut? As other developers start to contribute going forward and submit pull requests, once a pull request gets merged in it would be great to know if it was in a bintray release or not, and it’s hard to tell as it currently stands.

Thanks! Mark

In general we don’t want to “delete” RPMs from bintray, once published. The version 0.81-369 is newer than 0.81-358, and yum update / yum install commands are aware of this. We found out some bug in the older RPM, and hence published the new ones to bintray with the fixes.

We will definitely need to update the Mingle card with a comment / flag saying, released to bintray, or one can look at the release notes to figure out which ones are up-to-date. Some inputs here would help on what could be a good potential strategy to communicate (or correlate) this. We usually want to release to bintray a minor version only-if the accumulated fixes are deemed important enough to be released.

/cc: @sushma, @vinay, @angshuonline for inputs.

I think in Github we should “tag” the commit that has made it into “bintray” with the RPM / Release Minor version. That way all commits before that are guaranteed to be in bintray. What do others think?

1 Like

The Home page of Bahmni shows various details about the build - like GoCD details, bahmni-core SHA, bahmniapps SHA etc. The following is an example. click on the small (i) icon on the Logo.

Yes, this was what I was thinking as well, would make it easy (hopefully) to map a bintray release to all the commits in it.