Update to MapStore 2021.02.xx

[offtherailz]

We have to also include the following:

• Update of the georchestra MS project master to point to latest MapStore stable 2021.02.xx

[catmorales]

Tag the current version on branch 1.2.x with a fixed version

We will have to take advantage of this evolution to tighten up the naming of versions, tags, bugfixes and docker images.
Can we already rely on year-version-bufix on the tag ? It seems to me that this is what you had started on https://github.com/georchestra/mapstore2-georchestra/tags.
@tdipisa , @offtherailz What do you think and do you have any constraints at this level?

@fvanderbiest , @landryb , @pmauduit could you give the better recommandations to be in agreement with geOrchestra?

[landryb]

i'm not a specialist in release management, but i'd say the 'stable' branch of mapstore2-georchestra should be in a releaseable state all the time, and get tagged everytime a georchestra release is tagged/done (eg 20.1.4, 21.0.x, etc).. And since the repo/project is "a bit" independent, it could still get bugfixes and tags separately (eg doesnt "need" a new full georchestra release at each bugfix batch, just tag this repo with 20.1.4.1 21.0.x.1 etc)

[offtherailz]

Ok, accordingly with the current status I have the tag 20.1.3-georchestra, then a series of commit from your team.

I suggest to create a stable branch 20.1.x, and then continue development on master for future release, back-porting all bug fixes.
Please tell me from witch commit I should create the branch, after the tag (included).

[landryb]

i'll defer to @fvanderbiest as i'm not 100% aware of camptocamp's strategy wrt submodules/merges/backports/etc..

[MaelREBOUX]

Hello @offtherailz

The PSC recommend to now name the tags and releases of mapstore2-georchestra in the same way as geOrchestra does.
I think it is very close of the rules for MapStore2.

The doc which describe the release system is here : https://github.com/georchestra/georchestra/blob/master/docs/releases.md

One more thing, please, in the release text, add the info of the mapstore2 backport release to be clear on which version is used.

[offtherailz]

Does it makes sense to do this operation or should I proceed only on master ?

• rename the current 1.2.x into 20.1.x
• Commit the pom on stable in 20.1.0 (or 1 and tag previous)
• Then tag it with a release (please indicate the commit you are actually using)
• Commit again pom on stable in 20.1-SNAPSHOT.

[landryb]

yes that seems sensible (@pmauduit ? you're the maven expert), right now the last release is https://github.com/georchestra/georchestra/releases/tag/20.1.4

[landryb]

fwiw, successfully tested update from #428 on my dev instance, will test runtime now (really nicer compact menus and better default font !). depends on georchestra/datadir#224 merge too.

[jusabatier]

Also tested here, I have my uploaded plugins that have disappear.

They still in the extensions directory, but it looks like Mapstore can't find them.

I also have this in logs :

PropertiesLoaderSupport.loadProperties() - Could not load properties from URL [file:/mapstore.properties]: /mapstore.properties (Aucun fichier ou dossier de ce type)

[jusabatier]

Here : https://github.com/georchestra/mapstore2-georchestra/search?q=mapstore.properties

Should look in ${georchestra.datadir}/mapstore/mapstore.properties

[offtherailz]

Please make sure to do these operations:

https://mapstore.readthedocs.io/en/latest/developer-guide/mapstore-migration-guide/#data-directory-has-been-reorganized-and-is-now-available-also-for-product

• Move all .json and .json.patch files in configs folder (except extensions.json)
• Move the directory dist/extensions to simply extensions.
• The file extensions.json have to be moved in extensions/extensions.json.
• Edit the file extensions/extensions.json changing the paths from dist/extensions/<Plugin-Name>/... to <Plugin-Name>/...