We at PIH are close to being ready to begin testing the bleeding edge Core version 2.2 (and hopefully have it running in a production environment within the next couple of months!).
To do so, I’d like a stable version in the Maven Repo for us to reference… any objections to us doing an “alpha” release if we need to? I was thinking “2.2.0-alpha-1” which would allow for a “2.2.0-alpha-2” if we needed it.
Alternatively, I could do something called “2.2.0-pre-alpha-1” if we didn’t think we were at the alpha stage yet.
Note I’m not planning on doing any ticket management around this, etc, I just want to get an artifact deployed somewhere so we can being testing and fixing bugs as quickly as possible. We may be able to do this just by relying on specific snapshots, but I’m not sure if that will be feasible.
Thoughts? I will likely be doing this early next week if I don’t hear any objections.
To be clear, you’re suggesting an early release of OpenMRS corebefore the imminent Platform 2.2.0 release, which should include OpenMRS core 2.2.0?
If you are going to tag an alpha release, I’d suggest following our semantic versioning conventions, which would be “2.2.0-alpha” (and, if another alpha was required, “2.2.0-alpha2”).
I was able to just tag the specific commit of Core we are going to deploy, and then tell all developers working on PIH-EMR (there’s only a few of us) to clone core, check out that tag, and then “mvn watch” it.
I was going to do an alpha release so that our devs wouldn’t have to through the above process, but I discovered that the SDK thinks that “2.2.0-SNAPSHOT” is more recent than “2.2.0-alpha” (which actually may be correct) and so that wasn’t working 100%… I started going down a path of trying to get that to work, but then I stepped back and realized that the only reason I was doing this at all was to simplify things for the rest of our team, so if it ended up making things more complicated, it was’t really worth it…
That being said, whenever OpenMRS is ready to cut a “2.2.x” branch (and roll “master” to 2.3.x) we can just switch building against 2.2.0-SNAPSHOT, but it sounds like we are still waiting on a few tickets before we do this?
No objections on my end… I’m not sure if we are still waiting for some other tickets to be finished, but, if so, I’d be fine with cutting an alpha and then we can backport the remaining tickets into the 2.2 line when the commits are ready.
@reubenv is the 2.2.0-alpha release something you can do, or are you looking for someone to do it?
@mogoodrich Assuming that this has to be followed, I can do the release myself if needed. However, I am gonna have to request for a bunch of permissions as required by the platform release and that might take some time. It would get done much faster if someone with experience and the necessary privileges could get it done.
@reubenv unfortunately I won’t have time to take it up, at least not in the next couple weeks, which are going to be crazy busy. I might have time to work on it at the conference or afterwards.
I’m working on at least getting the other modules released now.
Sure thing @mogoodrich , you are already doing a lot for this release by taking up the responsibility of releasing so many modules yourself, thanks for that