On our technical roadmap, it says that the next release version of the platform is 2.2, I don’t think core 2.2 would be ready if we intend to have a platform release before the end of the year, shouldn’t the next release of the platform be 2.1? Or is it because core 2.1.1 is a non LTS version?
We have already released OpenMRS Core 2.1, and therefore the next version of the platform should be 2.2. (Releasing a non-LTS openmrs-core still consumes a version number from the platform.)
Or are you suggesting that we do a Platform 2.1.(something) release off of the openmrs-core 2.1.x line that merely adds additional testing, bugfixes, and “certification” on top of the non-LTS release we did earlier, but does not bring in any additional features? That’s an intriguing idea: it would be quicker to do, and thus doable within the calendar year…
That’s what I was suggesting, we can do a Platform 2.1.1 release since it’s more attainable, we would just have to pick the module versions that we want to package along with it and do more testing, if we are to do a 2.2 release there is much more to be done and negotiation of what goes into it and what doesn’t.
Hello @wyclif, I hope you are fine. Did you harmonize the issue about what should be released, Platform 2.1.1 versus Platform 2.2. I have not seen the conclusion about it.
Hello friends let’s suggest the date for the release of Platform 2.2. Any suggestions? Thanks
Several developers were on today’s design forum and discussed the pros & cons of options for the impending platform release:
- Release Platform 2.2 from master (including all bug fixes, but omitting any new features or complicated bug fixes)
- Sorting through all commits in master since the 2.1.x branch and properly leaving out any new features or complicated bug fixes was felt to be much work to get done and get a release out in 2017.
- Release Platform 2.2 using Core 2.1.1
- Since we want to keep Core & Platform versions synchronized, releasing Platform 2.2 would require a new 2.2.x branch that would basically be 2.1.x with few if any changes, so not worth the effort.
- Release Platform 2.1.2 using Core 2.1.1 + updated modules
- More feasible to get done in 2017, but would miss out on bug fixes in master.
- Release Platform 2.1.2 using Core 2.1.1 along with a few key bug fixes from master + updated modules
- Our best option. Leveraging Core 2.1.1 allows us to fast-track the release, but we could still take the opportunity to select a handful of key bug fixes in master that have not yet been backported to be included.
So, the consensus, in order to try to get a release out before the year ends, was to leverage have a Platform 2.1.2 release that uses Core 2.1.1 along with a handful of key bugfixes from master + updated modules. @wyclif should be posting about this soon, asking folks to nominate any straightforward bug fixes (that have been fixed in master but not yet backported) to be included in the release.
@irenyak1 I wrote to the community here on talk about picking the tickets to go into the release, from the OpenMRS roadmap there is 2 IDGEN module tickets that are not complete, do you mind following up with the developers they are assigned to? Thanks!
Ok @wyclif, I will follow them up.Thanks.