On 06/20/2016 01:10 PM, Fabien Boucher wrote: > Hi, > > I wanted to share we you my thoughts about the upgrade. We used to test one > upgrade path in our CI at each > submitted patchset (N-1 -> MASTER) mainly because we suppose that other SF > operators follow the last SF version > closely, and even it they don't, we suppose they will perform an upgrade by > steps (from 2.2.0 to 2.2.1 to 2.2.2) > > In the meantime we "support" (but not tested) other upgrade paths: > > (From the repo at (taggedRelease 2.2.2 patch)) > ./C7.0-2.2.1/C7.0-2.2.2 ** > ./C7.0-2.2.2/C7.0-2.2.3 > ./C7.0-2.1.8/C7.0-2.2.3 > ./C7.0-2.1.8/C7.0-2.2.1 > ./C7.0-2.1.8/C7.0-2.2.2 * > ./C7.0-2.1.8/C7.0-2.2.0 > ./C7.0-2.2.0/C7.0-2.2.1 > ./C7.0-2.2.0/C7.0-2.2.2 * > > Regarding C7.0-2.2.1 to C7.0-2.2.2 (**): We have a CI job so we test the > upgrade > (previous release -> last release) and this make us quite confident about it. > > Regarding the others (*) I don't get the point to keep them and I suggested > to remove them > because there are not tested in the CI. > Nevertheless we could support an upgrade path such as (n-2 release -> last > release) > like 2.2.0 to 2.2.2 but this should be tested in the CI. And this can ends up > with > something more "official" where we support two upgrade paths: from N-1 or > N-2 to N. > > 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. 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/ Regards, -Tristan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
