release notes improvement

[pmauduit]

Just a rapid note on what has been done today

I tried to follow the release procedure, but at some point I found more convenient to diverge a bit.

1. created a branch from master
2. moving from 21-SNAPSHOT (incl. geonetwork submodule) to 22-SNAPSHOT
3. once the CI (github actions) was all green, created a new commit (incl. geonetwork) with fixed version 22.0.0
4. checked that everything was still green
5. some gh actions had been updated already (pushing if ref 21 -> 22), but 2 were missing (gn, and df), so I needed to force-push and recreate the tag
6. in the meantime @landryb gave a hand on buildbot so that we can have 1. new repo in reprepro for deb packages 2. new builders targeting the branch (main georchestra repository + cas6). we decided to create a 22.0.x branch in georchestra/georchestra-cas-webapp, because it was more convenient to build the debian package.
7. We have now 22.0.x images following the branch + 22.0.0 docker images being generated on docker-hub (only one has not been generated, which is the datafeeder-frontend. Anyway, the repository georchestra/geonetwork-ui did not budge, and there already is a 22.0.0 tag when I worked on the gh actions several days ago.

Still TODO:

• commit in 22.0.x branch so that version is back to 22.0.1-SNAPSHOT (or whatever else more relevant, not sure)
• commit in master branch so that version is 22.0-SNAPSHOT

[pmauduit]

We still have an issue with debian package calculation (see talk with @landryb on IRC). Version should be something like:

For "pure georchestra components" (sp, extractorapp, mfapp ...):

• branch master: should be 99.master+<date>~<short commit>
• maintenance branch (e.g. 22.0.x): should be <branch name>+<date>~<short commit>

For integrated components which also have a life in their upstream repo: <upstream version>.<branch from geor>+<date>~<short commit>

[pmauduit]

Also, when doing a minor version release, we shall not forget to set a tag onto georchestra/georchestra-cas-server as well, and georchestra/mapstore2-georchestra

[pmauduit]

About geonetwork since 22.0.x series

On 22.0.x series for patch release, due to inter-dependencies between geonetwork & georchestra repositories, one need to commit so that georchestra-integration/pom.xml refers to the tag / release, e.g.:

https://github.com/georchestra/geonetwork/blob/22.0.1/georchestra-integration/pom.xml#L15

This will be used to get the expected versions of the jars being built into georchestra/georchestra ; as a result, do not expect the build to successfully work into the geonetwork repository, but it should realign once georchestra/geochestra will have the release commit + the submodule properly updated.

[pmauduit]

Also when releasing, you have the possibility to draft a release into the github ui, which lets you set a tag which will be created once actually releasing. Pay attention that by default, github will prefix the tag with a v, which is not the convention in geOrchesta since then.

I don't really mind, we can stick with x.y.z for tags, but since I did the mistake with 20.1.7 ...

[pmauduit]

Another thing is that I'm now using major.minor.patch-SNAPSHOT versions on 22.0.x, which seems coherent with what other projects are doing (e.g. spring)

[pmauduit]

... and trying to update one of our environment, I realize that I forgot about georchestra/geonetwork-ui for the frontend part of the datafeeder. Seriously ....

Not needed anymore, as there is a datafeeder-ui in the main repository.

[landryb]

lets split georchestra into multiple repositories, it will be simpler to manage

;)

[pmauduit]

In case of releases, one also have to update the website, e.g.: https://github.com/georchestra/georchestra.github.io/pull/124/files

[pmauduit]

The tags used to "materialize" the releases should not begin with a "v", else it will make the debian package version calculation fail.

[pmauduit]

When releasing, we need to first modify the GN submodule, like: https://github.com/georchestra/geonetwork/commit/2c325ca24daa23a43fe1d48b81f05c4596695b2f before updating the GN submodule accordingly in the georchestra repository.

This is due to a kind of circular dependency between GN & geor, and I think we should fix it (maybe by having the necessary jars from geOr in their own repositories ?)

[fvanderbiest]

Thanks for the feedbacks. https://github.com/georchestra/georchestra/blob/master/RELEASE_PROCEDURE.md to be improved

[fvanderbiest]

Once the geonetwork tag has been set, what about georchestra.version in georchestra/geonetwork/georchestra-integration ? https://github.com/georchestra/geonetwork/blob/49f983e8a584255d7e1510a926ab43cd933357fd/georchestra-integration/pom.xml#L15

[jeanmi151]

[DONE] update tags into .github/workflows : https://github.com/georchestra/georchestra/blob/23.0.x/.github/workflows/ldap.yml#L42

Also I would love to clean/delete old branches that are not needed anymore : https://github.com/georchestra/georchestra/branches and maybe archive historical old versions ! need to create version in CAS repo too : https://github.com/georchestra/georchestra-cas-server

git fetch --all git checkout -b 23.0.x vim gradle.properties (change versions in it) git add gradle.properties git commit -am "23.0.x branch" git tag 23.0.0-georchestra git push --set-upstream origin 23.0.x --tag Create release in GH interface

missing also repo : https://github.com/georchestra/mapstore2-georchestra

git checkout -b 2023.05.xx

[pmauduit]

Mapstore2 has a custom release procedure here: https://github.com/georchestra/mapstore2-georchestra#release-procedure

If we want to materialize via a tag / release on the mapstore2 repository (topic still in discussion in the georchestra community), then we should not create branches, normally setting a tag on the head of the stable branch should make it.

[landryb]

according to the release procedure, the version should match the underlying mapstore2 version in the submodule, so still 2022.02.xx for now. Please remove https://github.com/georchestra/mapstore2-georchestra/releases/tag/2023.05.xx-geOrchestra & the 2023.05.xx branch :)

yeah i know it's a mess...

[jeanmi151]

@landryb if you want to add something (comment here or elsewhere) to the RELEASE_NOTES you can add stuff here : https://github.com/georchestra/georchestra/pull/3970

once all comment will be added I guess we can close this ticket :)

[landryb]

maybe the georchestra release procedure should just mention that mapstore2-georchestra has its own release procedure which should be followed when doing a release of georchestra ?

note that mapstore2-georchestra will be updated to mapstore 2023.01 in georchestra/mapstore2-georchestra#614, which will work with 23.0 or the next version of georchestra.

When everything is done on https://github.com/orgs/georchestra/projects/13, then a new 2023.01.xx release will be done in georchestra/mapstore2-georchestra.

[jeanmi151]

maybe the georchestra release procedure should just mention that mapstore2-georchestra has its own release procedure which should be followed when doing a release of georchestra ?

Feel free to add it into my PR : https://github.com/georchestra/georchestra/pull/3970 :smile:

[fvanderbiest]

maybe the georchestra release procedure should just mention that mapstore2-georchestra has its own release procedure which should be followed when doing a release of georchestra ?

I'm strongly opposed to this, as it puts a burden on the release team. Instead, I'd rather have mapstore out of the release process. Correct me if I'm wrong, but I think any MapStore version can be used with any geOrchestra version.

[landryb]

maybe the georchestra release procedure should just mention that mapstore2-georchestra has its own release procedure which should be followed when doing a release of georchestra ?

I'm strongly opposed to this, as it puts a burden on the release team. Instead, I'd rather have mapstore out of the release process. Correct me if I'm wrong, but I think any MapStore version can be used with any geOrchestra version.

Many MapStore versions are compatible with many geOrchestra versions, but i wouldnt use 'any'.

This discussion stemmed by the fact that a release was done in ms2-georchestra, without following its release procedure.

So far there hasn't been a discussion if mapstore was 'part of georchestra' or not (to me, the general consensus was that it replaced mapfishapp as the default viewer, others might disagree), and if releases in the repository should be done in conjunction with georchestra like it was done for cas-server. Cc'ing @MaelREBOUX & @catmorales for insights on this.

Fwiw, i've added 'mapstore 2022.02' as part of the highlights of this release on https://github.com/georchestra/georchestra/releases/tag/23.0.0

You can revert f4be35f if you like, but i find that situation deeply sad.

[pmauduit]

removing the milestone here, as this issue was more to document a process which might (have) evolve(d) since then