@jwnasambu as you can see in this commit: [maven-release-plugin] prepare for next development iteration · openmrs/openmrs-module-webservices.rest@9358bda · GitHub
You released version 2.38.0 and so the next development version cannot be 2.30.0-SNAPSHOT
I now get where the typo is. Thanks so much!
@dkayiwa I admit my mistake and own it. I am going to take some few hours to confirm every module has the right version. To to be honest some I wasn’t fixing the snapshot version with the intension it will be automatically calculated by the maven release plugin.
From the documentation here Releasing a Module from Bamboo - Documentation - OpenMRS Wiki, we set both the release and next development version.
You are right! To be honest the first modules I made a big blunder. I made my decision basing on this statement default next snapshot ( *maven.development.version* ) is empty, and calculated by the maven release plugin. and for sure it calculated for me 
Kindly I have raised a PR for this fix on this link.
I’m not surprised at all that this happened, I view this as a weakness in our release processes and scripts to be honest. The issues that you encountered @jwnasambu were easy to run into (too easy), and our scripts should make it much, much easier to do the right thing, and harder to run into these problems. Anyone who has done a lot of releasing in Bamboo has run into these kind of issues - you are definitely not alone.
@dkayiwa and @burke our Bamboo jobs and release scripts need to be smarter than requiring these variables to be set to particular values at release time. In my opinion we should not store these version values in our jobs over time, which is what leads to them having bad values. One should always be able to override, but the default as much as possible should always be to not have any explicit values set for these variables and to instead detect the release version and next development version based on the pom.
Maybe we can look at this together in an upcoming call and see if we can make some straightforward improvements.
I completely agree!
It was supposed to be a different module. But i have merged this too. 
True! Am going through every module. I have delayed pushing that PR because of power Issues but am about to notify you.
Kindly feel free to look at my PR at you convinient time please.
@jwnasambu for modules that have JIRA projects, can you also do the release of the versions in JIRA? Also ensure that the tickets are closed.
@dkayiwa Kindly how can I go about this module? The previous release version is higher than the current release version as reflected on this link GitHub - openmrs/openmrs-module-attachments: UI components and backend web services to upload, view and manage attachments within OpenMRS.
This module has two release lines. The 2.x branch for the older reference application and the master branch for 03
Kindly am facing the same challenge as the above but desire to fix it myself. Kindly where are the changes made? I have made some changes as reflected on the screenshot below but still the is not build reflected after saving my changes
You need to run a new build instead of an existing failed one.
Thanks so much for the guidance. It has worked!
@ibacher, @dkayiwa Before updating CIEL on the mdsbuilder ( though waiting for @akanter 's response on slack) I set-up the Reference Application server to confirm its running on platform 2.5.8 version. On running the server, its platform 2.6.0 which is running instead of 2.5.8. To fix the issue I raised a PR on this link fixed the distro.platform file with the 2.5.8 required info by jwnasambu · Pull Request #63 · openmrs/openmrs-contrib-ansible-docker-compose · GitHub to update the docker image. Kindly feel free to look through and guide on a proper way to fix the issue.
Thanks!
Are you sure?
Yes! I setup the server myself and it reflected platform 2.6.0.
