On 2020-06-10 23:56:41 +0200 (+0200), Thomas Goirand wrote: [...]
Is the re-tag of services THAT time/resource consuming? [...]
It means divergent tooling and process for releasing our libraries vs releasing our services, and additional cognitive load for projects to need to decide which deliverables should follow what release model.
When I'll look into my Debian Q/A page [1] I wont be able to know if I missed packaging final release just by looking at version numbers (ie: track if there's still some RC version remaining and fix...).
You don't know that today for our libraries either, since they branch from non-rc version numbers and may produce additional point releases in their stable/$cycle branch up until near the coordinated release.
I'd be for the opposite move: tagging libraries as RC before the final release would make a lot of sense, and help everyone identify what these versions represent. [...]
Except that they typically branch long, long before the coordinated release and need to have their version numbers included in requirements lists for other projects' master branches. It might be doable to have them use release candidates on the new stable branch until close to coordinated release and then tag them all with version numbers and update every requirements list to compensate, but that seems like it would turn into a massive scramble vs the one patch version here and there that they normally accrue late in the cycle.
With this proposal, every project will treat the scheduled first RC as the release time itself, and move on to work on master.
They already do. Right now when rc1 is tagged and the stable/$cycle branch is created from it, subsequent fixes enter master and get backported to stable/$cycle and then an rc2 (or 3, or 4...) is tagged in stable/$cycle as needed. At coordinated release time whatever the corresponding commit was for the last rcN tag was gets re-tagged as the release version, and in most cases that's identical to the rc1 tag (no additional fixes during release candidate period). The new proposal would follow the same process, just not stick rcN prefixes on the tags and increment the last number in the tag instead, then not do any re-tagging of the last tag at coordinated release time because the versions of the last tags are already normal version numbers.
Even worse: since they are supposed to be just RC, you'll see that projects will care less to be on-time for it, and the final version from projects will be cut in a period varying from start of what we used to call the RC1, to the final release date.
I don't see why you would expect this any more than today. Projects backport patches from master to the new stable/$cycle branch during this period already, the incentive to do that doesn't change based on what the tags created in that branch look like.
So this effectively, removes the pre-release period which we used to have dedicated for debugging and stabilising. [...]
You keep asserting this, but the plan is precisely intended to maintain this period, and says nothing about getting rid of it.
If that is what you want to do (ie: stop having release candidates), because of various reasons, just explain why and move on. I would understand such a move: - if we declare OpenStack more mature, and needing less care for coordinated releases. - if there's not enough people working on stable branches between RC and final releases. - if OpenStack isn't producing lots of bug-fixes after the first RCs, and they are now useless. [...]
The original plan as written explains exactly why: "We [...have] a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid." We already ask far too much of our project teams, and simplifying the release models and processes they have to understand and follow should ease some of their overall burden, freeing up their time for more important remaining tasks. -- Jeremy Stanley