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
