Closed ridoo closed 10 months ago
yes we should rethink the whole release and versioning part. Until yesterday i thought i would be a good idea to stick the version with the geonode versions. But after working on the artifacthub.io integration, I changed my mind.
I would suggest to start with a new release 0.1 which targets the latest official geonode container and document this inside the release notes. and then from there on make new releases and test define which version can be run with which release. Maybe at some point a geonode-k8s release can also run multiple geonode version.
What do you think about that?
What insights did make you change your mind regarding versioning?
The chart itself can have bugs, too, which have to fixed. I agree to decouple Chart version scheme from the GeoNode scheme. However, GeoNode version should be used for the appVersion
field.
let my try to scatter the helm chart use-case:
helm repo add geonode https://zalf-rdm.github.io/geonode-k8s/
and are then bounded to a specific geonode-k8s release. This is further bind to a fixed appVersion (geonode version)release notes must always contain geonode app versions. so older geonode versions can be deployed with older chart version. As i wrote before i would prepare a new release 0.1.0, as soon as we have the following issues fixed: #27, #51
@ridoo what do you think?
sounds good. What speaks against 1.0.0
? I think you made a good starting point already.
@mwallschlaeger This issue can be closed IMO
Bug Description
For version
4.1.0
the Helm chart refers to a non final image version4.1.x
. This is suboptimal, as it will not preserve using the same image in the future.@mwallschlaeger what do you think? Shall we consider to re-release the Chart?