You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2019/05/10 09:06:29 UTC
Version numbers proposal
Hello all
Apache SIS currently has 3 branches, but only one of them is released.
For understanding the purpose of those 3 branches, we need to remind the
status of GeoAPI:
* GeoAPI 3.0.1 is the latest release published by OGC.
* GeoAPI 3.1 is in development, not yet released by OGC, and aimed to
be fully backward compatible with GeoAPI 3.0.1.
* GeoAPI 4.0 is in development, not yet released by OGC, and contains
two kinds of incompatible changes:
o Incompatible changes in ISO/OGC standards (e.g. some classes
renamed, or some information reorganized in a different class
hierarchy).
o Incompatible changes if we want to leverage evolution of Java
language (e.g. use of java.time in replacement of
java.util.Date, or use of java.util.Optional).
The 3 branches of Apache SIS reflect those 3 three versions of GeoAPI:
* Apache SIS "master" branch implements GeoAPI 3.0.1 interfaces. This
is the only branch used for making Apache SIS releases. The next
planed release is Apache SIS 1.0.
* Apache SIS "geoapi-3.1" branch implements GeoAPI 3.1 interfaces.
This is a branch for developers, not to be released before OGC
publishes GeoAPI 3.1. When ready for a release, the version number
would be "Apache SIS 1.something" where "something" is currently
unknown.
* Apache SIS "geoapi-4.0" branch implements GeoAPI 4.0 interfaces.
This is a branch for developers, not to be released before OGC
publishes GeoAPI 4.0 (but snapshots and milestones are deployed on a
Maven repository outside Apache for use by Geotk - a sandbox for
future SIS features). When ready for a release, the version number
would be "Apache SIS 2.0".
The pom.xml files currently declare the following version numbers for
each branch:
* master: "1.0-SNAPSHOT"
* geoapi-3.1: "dev-1.0-SNAPSHOT"
* geoapi-4.0: "dev-1.0-SNAPSHOT" (same as geoapi-3.1).
I propose to change as below. Those changes would apply to versions
declared in pom.xml files only; the branch names would stay unchanged.
* master: "1.0-SNAPSHOT" (unchanged)
* geoapi-3.1: "1.future-SNAPSHOT"
* geoapi-4.0: "2.0-SNAPSHOT"
Though?
Martin
Re: Version numbers proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 10/05/2019 à 11:59, Werner Keil a écrit :
> Will SIS 2.0 also use Unit-API 2.0 (JSR 385) as opposed to 363 in the 1.x branch?
I think so. We will need to submit that upgrade proposal to OGC since
Unit-API is depended by GeoAPI, but I see no reason why there would be
objection.
Martin
Re: Version numbers proposal
Posted by Werner Keil <we...@gmail.com>.
Will SIS 2.0 also use Unit-API 2.0 (JSR 385) as opposed to 363 in the 1.x
branch?
Werner
Martin Desruisseaux <ma...@geomatys.com> schrieb am Fr., 10.
Mai 2019, 11:51:
> 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
>
>
>
Re: Version numbers proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 10/05/2019 à 12:20, Johann Sorel a écrit :
> 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.
No problem for using "X" instead of "future" - I'm neutral on that.
For geoapi-4.0, we can use "2.0" instead than "2.X" since we already
know what would be the version number of the release of that branch
(contrarily to "geoapi-3.1" where the exact SIS version number is still
unknown).
Martin
Re: Version numbers proposal
Posted by Johann Sorel <jo...@geomatys.com>.
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
>
>
Re: Version numbers proposal
Posted by Martin Desruisseaux <ma...@geomatys.com>.
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
Re: Version numbers proposal
Posted by Johann Sorel <jo...@geomatys.com>.
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.
Johann
On 10/05/2019 11:06, Martin Desruisseaux wrote:
> Hello all
>
> Apache SIS currently has 3 branches, but only one of them is released.
> For understanding the purpose of those 3 branches, we need to remind the
> status of GeoAPI:
>
> * GeoAPI 3.0.1 is the latest release published by OGC.
> * GeoAPI 3.1 is in development, not yet released by OGC, and aimed to
> be fully backward compatible with GeoAPI 3.0.1.
> * GeoAPI 4.0 is in development, not yet released by OGC, and contains
> two kinds of incompatible changes:
> o Incompatible changes in ISO/OGC standards (e.g. some classes
> renamed, or some information reorganized in a different class
> hierarchy).
> o Incompatible changes if we want to leverage evolution of Java
> language (e.g. use of java.time in replacement of
> java.util.Date, or use of java.util.Optional).
>
> The 3 branches of Apache SIS reflect those 3 three versions of GeoAPI:
>
> * Apache SIS "master" branch implements GeoAPI 3.0.1 interfaces. This
> is the only branch used for making Apache SIS releases. The next
> planed release is Apache SIS 1.0.
> * Apache SIS "geoapi-3.1" branch implements GeoAPI 3.1 interfaces.
> This is a branch for developers, not to be released before OGC
> publishes GeoAPI 3.1. When ready for a release, the version number
> would be "Apache SIS 1.something" where "something" is currently
> unknown.
> * Apache SIS "geoapi-4.0" branch implements GeoAPI 4.0 interfaces.
> This is a branch for developers, not to be released before OGC
> publishes GeoAPI 4.0 (but snapshots and milestones are deployed on a
> Maven repository outside Apache for use by Geotk - a sandbox for
> future SIS features). When ready for a release, the version number
> would be "Apache SIS 2.0".
>
> The pom.xml files currently declare the following version numbers for
> each branch:
>
> * master: "1.0-SNAPSHOT"
> * geoapi-3.1: "dev-1.0-SNAPSHOT"
> * geoapi-4.0: "dev-1.0-SNAPSHOT" (same as geoapi-3.1).
>
> I propose to change as below. Those changes would apply to versions
> declared in pom.xml files only; the branch names would stay unchanged.
>
> * master: "1.0-SNAPSHOT" (unchanged)
> * geoapi-3.1: "1.future-SNAPSHOT"
> * geoapi-4.0: "2.0-SNAPSHOT"
>
> Though?
>
> Martin
>
>