Openmrs platform 2.2-alpha Release Impending

Hey,

I’m excited to inform the community that the awaited openmrs platform 2.2-alpha is just next door :smile:

Just if factors remain constant, the release will happen before the end of November 28; that’s tomorrow.

Bundled modules

  • Webservices.rest -version TODO
  • OWA - version TODO
  • FHIR - version TODO

I presume the above are the required bundled modules. Maybe what I’m not sure of is the versions. Are we depending on their latest versions?

cc: @dkayiwa, @mogoodrich

2 Likes

We actually need to do the 2.2.0-alpha of core to do the latest release of REST web services… so I’m thinking likely we should release 2.2.0-alpha core, then do a new release of REST web services, and then do the 2.2.0-alpha platform release.

So, that being said, I think we could just concentrate on the 2.2.0-alpha Core release for now, that will allow us to release the latest REST web services and get the Ref App 2.9 release (which just depends on Core 2.1.x) out the door. We can figure out the 2.2.0-alpha platform release after that.

Does that make sense to others? @dkayiwa

Take care, Mark

1 Like

If you have confirmed with modules’ release versions on the bin-tray go a head and release the platform its really over due.

Well looks like the Core release is different from the platform release.

Do we have a documentation around this? I’m just not sure now of how to proceed yet I’m desperately willing to learn. Ok could someone define me steps if we have no documentation in place?

cc: @dkayiwa, @mogoodrich

@mogoodrich that makes sense to me.

@samuel34 it is almost the same. The major difference is that the core release does not have any bundled modules.

@samuel34

For an “alpha” version of core, I think all you really need to do is the following:

For “If it is not a maintenance release, the release process should start from creating a maintenance branch,” just do steps 1 and 2

Note that the branch and CI plan should be called “2.2.x” not “2.2-alpha”… it should mirror the other “1.9.x” “1.10.x”, etc, branches…

Then we should be able to just do the release via CI. Does this make sense to you @dkayiwa? We’d set the release version to “2.2.0-alpha”… but do people know what we set the new “development” version to? Does it go back to “2.2.0-SNAPSHOT”? Do we just leave it was “2.2.0-alpha”?

Take care, Mark

1 Like

Yes the next development version goes back to 2.2.0-SNAPSHOT

@mogoodrich makes sense to me. :slight_smile:

@mogoodrich thanks for the directions.

What is done so-far

From this step, can I go ahead and release from CI?

Following these release steps under Steps to follow for all releases , is step 5 and 6 really required for the Core release? Can I just go ahead and release from CI without doing it!

cc: @dkayiwa

Let us get started like this:

The branch should be 2.2.x

And the tag should be 2.2.0-alpha

Yes, Nice catch that’s what I had exactly done. Can you proceed? @dkayiwa

Can you start by giving me urls pointing to the 2.2.x branch and the 2.2.0-alpha tag?

Nice catch @dkayiwa. Thanks for being sober; I had messed them up.

The tag should be: 2.2.0-alpha

sorry again. Deleted old and created a new tag

tag : https://github.com/openmrs/openmrs-core/releases/tag/2.2.0-alpha

Next?

cc: @dkayiwa

@dkayiwa I have also updated our CI plan to point to the new branch :slight_smile:

@samuel34 can you create pull requests for the restwebservices and coreapps modules to switch their versions from wherever you find them as 2.2.0-SNPASHOT to this tag and confirm they all compile?

@samuel34 can you share a link to the CI plan to release this? Did you use the CI plan to release and hence create this tag?

@dkayiwa https://ci.openmrs.org/chain/viewChain.action?planKey=TRUNK-OC2X

@samuel34 if you created the tag manually, can you delete it? Then use the CI plan to release, and set the release version as 2.2.0-alpha and the next development version as 2.2.0-SNAPSHOT

That way, the 2.2.0-alpha artifacts will be uploaded and hence be ready to be referenced as dependency versions in the webservicesrest and coreapps modules, before you can create compiling pull requests for them.