Hi Tristan, >> >> In order to do that we can have two jobs: >> - upgrade test from N-2 >> - upgrade test from N-1 >> >> Furthermore I think we should remove SF_PREVIOUS_VER from the role_config.rc >> and >> compute it based on tags detection. Upgrade CI jobs will be then able to >> easily compute >> which version to install before performing the upgrade. >> >> Please share your thoughts too :) >> >> Cheers, >> Fabien >> > > Hello Fabien, > > I'd like we formalize semver (Breaking.Feature.Fix). For example in > software-factory we have: > 1.x.y: puppet master architecture > 2.0.y: puppet masterless architecture > 2.1.y: gerrit upgraded to version 2.11.5 > 2.2.y: deployment assisted by ansible > > In theory, we should consider every Breaking.Feature as stable branch > and maintain upgrade path from last stable to latest release. > Realistically, we could only care about the last stable and last version.
Beside the theory I think you should also consider the pragmatic case where a platform wont be updated every release, so I would add a path from 2.2.2 to 2.2.4 for instance (N-2 to N) to your proposal. > I've proposed to clean-up upgrade path for future releases, basically: > 2.1.8->2.2.4 and 2.2.3->2.2.4 : > http://softwarefactory-project.io/r/#/c/4436/ But one important point imo is that we test them in our CI, if your are agree with that point. This thread can ends up with a story about keeping only the relevant upgrade paths + a re-factoring of the way we run the upgrade test in the CI. Cheers, Fabien _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
