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