Change to 3.11-SNAPSHOT

[jodygarnett]

This allows dependent projects to depend on the branch, without interruption each time a release is made.

This is especially useful for schema plugins referencing geonetwork via parent, and transitive dependencies.

See #5096

[juanluisrp]

Can you describe the benefits of this change?

Dependent projects can depend on the branch already without needed to change GeoNetwork version numbers. For example a dependent project can add

<dependency>
    <groupId>org.geonetwork-opensource</groupId>
    <artifactId>domain</artifactId>
    <version>[3.10,3.11)</version>
</dependency>

to depend on GeoNetwork's domain artifact at 3.10.x versions.

[jodygarnett]

Can you describe the benefits of this change?

With schema plugins using geonetwork as a parent, the 3.11-SNAPSHOT allows these to remain unchanged as each 3.11.0 and 3.11.1 release is made. Previously these would need to change from 3.11.0-SNAPSHOT to 3.11.1-SNAPSHOT.

Also https://medium.com/@MichaKutz/legit-but-useless-maven-version-ranges-explained-d4ba66ac654

[jodygarnett]

example a dependent project can add

<dependency>
    <groupId>org.geonetwork-opensource</groupId>
    <artifactId>domain</artifactId>
    <version>[3.10,3.11)</version>
</dependency>

to depend on GeoNetwork's domain artifact at 3.10.x versions.

This is not the case, because it is not a dependency we are worried about ... it is the parent reference:

  <parent>
    <artifactId>schemas</artifactId>
    <groupId>org.geonetwork-opensource.schemas</groupId>
    <version>3.11-SNAPSHOT</version>
  </parent>

And the parent reference do not support versions.

[josegar74]

@jodygarnett I understand the nature of this change, but want to be sure that is change is fine, as we "loose" from the pom.xml files the current patch version.

In all the docs I've seen (I'm not an expert in maven), I see like this versioning:

3.11.0-SNAPSHOT
3.11.0
3.11.1-SNAPSHOT
3.11.1
...

That is the current case in GeoNetwork.

With the change it will be like:

3.11-SNAPSHOT
3.11.0
3.11-SNAPSHOT
3.11.1
...

In 3.10 the schemas/pom.xml has a fixed value, unfortunately it's 3.7 instead of 3.10 as should be (probably introduced before GeoNetwork 3.8 and was not updated on the following releases):

core-geonetwork/schemas/pom.xml

Line 34 in d71ee16

<version>3.7</version>

core-geonetwork/schemas/iso19139/pom.xml

Lines 5 to 9 in d71ee16

	<parent>
	<artifactId>schemas</artifactId>
	<groupId>org.geonetwork-opensource</groupId>
	<version>3.7</version>
	</parent>

In master branch was replaced to use the full version.

If 3.10.x branch, it is updated to use the correct 3.10 version and master also to use 3.11 numbering for the schemas/pom.xml version, would not be accomplished a similar result while keeping in the SNAPSHOTS versions the patch number?

If it's not the same result, as long as the change doesn't make a wrong usage of version numbers (how is this handled in GeoServer for example?) and other developers are fine, it's ok for me. @fxprunayre any opinion about this?

[jodygarnett]

Replying to individual topics:

With the change it will be like:

3.11-SNAPSHOT
3.11.0
3.11-SNAPSHOT
3.11.1
...

This is correct, there is no difference between . and - for comparing version numbers. So SNAPSHOT represents the "latest" in the series 0, 1, SNAPSHOT. See this excellent post for details.

In 3.10 the schemas/pom.xml has a fixed value, unfortunately it's 3.7 instead of 3.10 as should be (probably introduced before GeoNetwork 3.8 and was not updated on the following releases):

Yes making use of SNAPSHOT correctly is a key requirement to make use of the repo.osgeo.org for nightly build and preventing builds from tripping over each other if you are building multiple branches locally. If you did not build locally this 3.7 version actually ends up bringing the transitive SNAPSHOT dependencies into your build resulting in conflicts. Actually maven believes 3.7 is stable and you end up breaking maven repository logic and never quite know what is going to happen.

In master branch was replaced to use the full version.

Master also is required to add 3.10-SNAPSHOT (rather than just 3.10).

If 3.10.x branch, it is updated to use the correct 3.10 version and master also to use 3.11 numbering for the schemas/pom.xml version, would not be accomplished a similar result while keeping in the SNAPSHOTS versions the patch number?

It would not have the same result as 3.10-SNAPSHOT is handled in a distinct manner, published to an entirely different snapshot repository, 3.10 is considered a stable release and is published to the release repository.

The meaning of 3.10-SNAPSHOT indicates it is the "latest" build of the 3.10.x branch, either built by jenkins (a nightly build), or built locally by the developer today. Maven SNAPSHOTS are checked once a day, unless you use -U to force an update from repo.osgeo.org.

If it's not the same result, as long as the change doesn't make a wrong usage of version numbers

The use of 3.10 and 3.10-SNAPSHOT are not the same.

(how is this handled in GeoServer for example?) and other developers are fine, it's ok for me. @fxprunayre any opinion about this?

It is handled in GeoServer in the same way as this pull-request:

• GeoServer 2.18.x branch uses 2.18-SNAPSHOT version, link to pom.xml
• GeoServer 2.18.0 tag uses 2.18.0 version, link to pom.xml

[jodygarnett]

In 3.10 the schemas/pom.xml has a fixed value, unfortunately it's 3.7 instead of 3.10 as should be (probably introduced before GeoNetwork 3.8 and was not updated on the following releases):

As I understand it schema plugin developers "liked" using 3.7 as one could reuse their schema plugin checkout between different version of geonetwork, depending on building the correct version of geonetwork locally to pick up the desired transitive dependencies. It took me a long time to understand this because it is not respecting the maven build system rules.

Consider 3.10.0 release changes:

• GeoNetwork 3.10.0-SNAPSHOT, schemas/pom.xml 3.7, schema plugin parent 3.7(publishing to repo.osgeo.org with transitive dependencies on3.10.0-SNAPSHOT`)
• GeoNetwork 3.10.0-0, schemas/pom.xml 3.7, schema plugin parent 3.7(getting transitive dependencies3.10.0-0if you build locally, getting3.10.0-SNAPSHOT` from jenkins otherwise)
• GeoNetwork 3.10.1-SNAPSHOT, schemas/pom.xml 3.7, schema plugin parent 3.7(publishing to repo.osgeo.org with transitive dependencies on3.10.1-SNAPSHOT`)

This is convent because schema plugin developers do not have to change their pom.xml each release.

It is unstable as the artifact fetched for schemas/pom.xml 3.7 changes over time:

• GeoNetwork 3.10.0-SNAPSHOT, schemas/pom.xml: publishing to repo.osgeo.org with transitive dependencies on 3.10.0-SNAPSHOT
• GeoNetwork 3.10.0-0, schemas/pom.xml 3.7: getting transitive dependencies 3.10.0-0if you build locally, getting3.10.0-SNAPSHOT` from jenkins nightly build otherwise
• GeoNetwork 3.10.1-SNAPSHOT, schemas/pom.xml: publishing to repo.osgeo.org with transitive dependencies on 3.10.1-SNAPSHOT

To make this work developers build geonetwork locally each time.

[jodygarnett]

After this pull request the 3.10.6 release changes look like:

• GeoNetwork 3.10.6-SNAPSHOT, schemas/pom.xml 3.7, schema plugin parent 3.7`
• GeoNetwork 3.10.6-0, schemas/pom.xml 3.7, schema plugin parent 3.7`
• GeoNetwork 3.10-SNAPSHOT, schemas/pom.xml 3.10-SNAPSHOT
• GeoNetwork 3.10.7, schemas/pom.xml 3.10.7-0
• GeoNetwork 3.10-SNAPSHOT, schemas/pom.xml 3.10-SNAPSHOT

This is convent because schema plugin developers do not have to change their pom.xml each time geonetwork releases, they only need to change when they wish to make a release.

[josegar74]

About my comment:

If it's not the same result, as long as the change doesn't make a wrong usage of version numbers

The point was to make sure that the usage of SNAPSHOT without patch version (3.11-SNAPSHOT) is valid one, as at least the docs I've seen use the patch version. If it's not used we "loose" the info about the current patch, that otherwise using proper tags, should be fine. From your description seem that this usage is also fine, so fine for me.

Thanks a lot for the detailed information about the issues to solve with this change.

[jodygarnett]

I would like to catch this PR promptly (ideally before schema plugins change to 3.10.7-SNAPSHOT)

[jodygarnett]

@josegar74 the release script changes should now be included here