If we keep sis version numbers, maybe just the 'X' can do the job.
* master : "1.0-SNAPSHOT"
* geoapi-3.1: "1.X-SNAPSHOT"
* geoapi-4.0: "2.X-SNAPSHOT"
I've never seen a 'future' in a version name, I find it odd.
Johann
On 10/05/2019 11:51, Martin Desruisseaux wrote:
Le 10/05/2019 à 11:33, Johann Sorel a écrit :
Since those branches are made to match a given geoapi version we could
include it in the version number :
* master : "1.0-SNAPSHOT"
* geoapi-3.1: "GEOAPI-3.1-SNAPSHOT"
* geoapi-4.0: "GEOAPI-4.X-SNAPSHOT"
It would make it obvious and avoid conflicts with any futur geoapi
versions branches.
We could do, but above proposal replaces SIS version numbers by GeoAPI
version numbers… The proposal in my previous email was based on the
following assumptions:
* All SIS 1.x releases would need to be compatible with SIS 1.0 (and
even SIS 0.x) except for deprecated classes/methods. This implies
that SIS 1.x releases can only depend on GeoAPI 3.x.
* SIS 2.0 would be allowed to contain incompatible changes compared to
SIS 1.x. This implies that SIS 2.0 can depend on GeoAPI 4.0.
If we accept the above, then the "1.future-SNAPSHOT" and "2.0-SNAPSHOT"
proposals are equivalent to "GEOAPI-3.1-SNAPSHOT" and
"GEOAPI-4.X-SNAPSHOT" proposals, but using SIS version numbers (instead
than GeoAPI version numbers) in SIS artifact names.
Martin
