So indeed, you may need to merge branch specific upgrades tasks or fixes into the intermediate branches and likely this is why we have not tagged older branches (like ocata and pike) as EOL
I think there are two things in this thread. The first from weshay original mail, which doesn't clarify what 'removing stable/rocky' means - but I believe it means 'removing the ci jobs for stable/rocky' ...
I mentioned EOL and that branches are not tagged as such - to which you replied. I now understand both that we should not do that, and likely *why* ocata/pike aren't marked eol like some older branches.
Granted, no TripleO deliverables have the stable:follows-policy tag,
so as long as you're only referring to which branches of TripleO
repositories are switching to EOL you can probably do whatever you
want (assuming the TC doesn't object). If TripleO's upgrade
orchestration in stable/train is able to perform the Rocky and Stein
intermediate deployments, it would presumably work. The service
projects don't have the same luxury however, and so can only EOL a
particular stable branch if all older branches are already EOL.
thanks for the pointers and clarification. I apologise for the confusion - as I wrote above, I was mistaken about marking branches eol. We will not be doing this.
This thread is about removing the upstream ci/rdo periodic jobs for those branches - rocky and stein to be specific