edevosc2c
commented
7 months ago First meeting 13th February 2023
Attendees
@edevosc2c , @fvanderbiest , @catmorales, @tdipisa, @pmauduit, @f-necas, GOFFINET Rodolphe
Summary of the discussion
- Tobia is fine with whatever proposal as long as it's properly documented.
- Everyone seems to agree on the second proposal. Not much about the first one.
- Catherine explained that sometimes mapstore georchestra is dependent on some specific geoserver versions, hence some specific geOrchestra versions.
- About the second proposal, we do not know if we want
+or-. But this may conflict with some Debian packages told Pierre? - Good idea for compatibility matrix array. Compatibility matrix in release GitHub description + readme
- Need to create GIP georchestra
- François also proposed to only support one version mapstore at a time, with the normal georchestra version numbering. But may render georchestra not flexible.
What to do next
- Create a GIP for proposing the second proposal to the community.
Description
Currently, there exist two separate tag naming maintained by two groups of people. One is 202x.xx.xx-geOrchestra managed by GeoSolutions and the other one is the traditional 2x.x.x-georchestra managed by Camptocamp.
The purpose of this issue is to discuss and document on a common release versioning for the software mapstore2-georchestra in order to avoid two separate kind of releases.
Proposal
First proposal
The proposal is to follow the geOrchestra release versioning followed by the mapstore version : Example: 23.0.4-2023.02.00
When we release a new geOrchestra version like we do for all the other components, we release the amount of supported mapstore versions so if both 2022 and 2023 are supported for 23.x then we release:
If a new mapstore comes out but the geOrchestra version hasn’t changed, then we only bump the version number for mapstore like so:
This way, the users know which versions of mapstore are supported by a specific geOrchestra version. There is no guess what mapstore version will work with what geOrchestra version.
Second proposal
Keep the current versioning of mapstore-geOrchestra, but with an added number if we want to add more stuff into the code.
If we want to release new code without changing the mapstore code to a new version:
And we maintain a compatibility matrix with what mapstore version works with what geOrchestra version. Ideally in the README or somewhere accessible.