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 _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
