576076 - Do test release of 3.6.X.Y

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

[Chris AtLee [:catlee]]

For chemspill releases it would be handy to be able to do e.g. a 3.6.6.1 release based on 3.6.6 instead of having to do 3.6.7 and push back anything that used reference 3.6.7 to 3.6.8.

Let's run a 3.6.X.Y release through staging and see if it works, or what breaks.

Comment 1

[[e-mail] (:bhearsum)]

I think the trickiest part here is 3.x.y -> 3.x.y.z -> 3.x.y. So, I think it's important to do 3.6.x.y as well as the subsequent 3.6.x.

In the 2.0 days we did 3.x.y.z for the entire life of that browser, and it worked fine. There may be a couple of recent pieces of automation that don't work properly with 4 part versions, but I doubt it.

Comment 2

[Chris AtLee [:catlee]]

(In reply to comment #1)
> I think the trickiest part here is 3.x.y -> 3.x.y.z -> 3.x.y. So, I think it's
> important to do 3.6.x.y as well as the subsequent 3.6.x.

Do you mean 3.x.y -> 3.x.y.z -> 3.x.(y+1) ?

Comment 3

[[e-mail] (:bhearsum)]

(In reply to comment #2)
> (In reply to comment #1)
> > I think the trickiest part here is 3.x.y -> 3.x.y.z -> 3.x.y. So, I think it's
> > important to do 3.6.x.y as well as the subsequent 3.6.x.
> 
> Do you mean 3.x.y -> 3.x.y.z -> 3.x.(y+1) ?

Yeah

Comment 4

[Aki Sasaki (not active)]

I'm going to hazard a guess that while we'd like to know whether we can do this, it's less urgent now that we have a concrete plan for our next releases.

Comment 5

[Daniel Veditz [:dveditz]]

we do? we plan never to have an unexpected firedrill that messes with the pre-planned version numbers? It seems like the basic issue comes up a couple of times a year.

It's not "urgent", but it's not any "less urgent" than it was when filed--we'd already rejected doing "3.6.4.1" due to the uncertainty at that point.

Comment 6

[Chris Cooper [:coop] (he/him)]

Don't think this makes sense to do in the rapid release era.