685291 - RC builds don't identify themselves as RC

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Wil Clouser [:clouserw]]

If you look at package.json of the 1.1rc1 tag you'll see it identifies itself as version 1.1:  https://github.com/mozilla/addon-sdk/blob/1.1rc1/packages/addon-kit/package.json

That's great unless there is an rc2 and then you've got no way of telling the versions apart.  We're attempting to do test runs upgrading jetpacks on AMO and they are all coming back as upgraded to version 1.1, which is going to break stuff if we discover a bug that requires an rc2.

I imagine anyone else dealing with RCs will run into similar issues.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

(In reply to Wil Clouser [:clouserw] from comment #0)
> If you look at package.json of the 1.1rc1 tag you'll see it identifies
> itself as version 1.1: 
> https://github.com/mozilla/addon-sdk/blob/1.1rc1/packages/addon-kit/package.
> json

This is intentional and satisfies the constraint that an RC's internal state reflect the exact set of bits one intends to ship, such that only external changes need to be made to ship it as the final release (i.e. copying the file to a new name, pointing references at it, etc.).

Firefox does this too.  For example, Mac en-US 4.0rc2 <https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0rc2/mac/en-US/Firefox%204.0%20RC%202.dmg> and 4.0 final <https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0/mac/en-US/Firefox%204.0.dmg> have identical cksums:

mykbook:Downloads myk$ cksum Firefox\ 4.0*
2505812836 28116471 Firefox 4.0 RC 2.dmg
2505812836 28116471 Firefox 4.0.dmg

And while I don't see 5/6 RCs on the FTP server, in the rapid release era even betas like 6.0b5 identify themselves as the final release both in user-facing UI like the About dialog and in internal strings like the extensions.lastAppVersion and browser.startup.homepage_override.mstone preferences.

(But SDK betas do not do this, nor do I think they should.)


> That's great unless there is an rc2 and then you've got no way of telling
> the versions apart.  We're attempting to do test runs upgrading jetpacks on
> AMO and they are all coming back as upgraded to version 1.1, which is going
> to break stuff if we discover a bug that requires an rc2.

Umm, but we're only doing test runs, right?  So if we discover a bug that requires an RC2, can't we reset the test database and redo the test run?  And shouldn't we do that, since the real repack process is only going to involve a single repacking from 1.0 to whatever bits we eventually ship as 1.1?

It seems to me that in this case we are better off testing repacking to something that appears to be 1.1, since that's closer to what we'll actually do when it comes time to repack for real.  And since we aren't going to repack for real until after we ship 1.1, there isn't a chance that we'll need to repack for real twice with two different versions of the software that both identify themselves as 1.1.

Part of the point of testing in advance is to make sure that any blockers to repacking are identified and addressed before we ship 1.1.  Nevertheless, if one does slip through, and it prevents us from repacking for real after 1.1 is released, then we wouldn't ship another version called 1.1 anyway; rather, we'd ship something like 1.1.1 with the necessary change.

So it isn't clear to me how identifying the RC internally as 1.1rc1 is helpful to the repacking process.  It seems like we're better off identifying the RC internally as the final release, as we currently do.


But perhaps I misunderstand, or there's something I'm not seeing.  Maybe you can explain further?


Also cc:ing Brian, who has previously expressed reservations about the way we ship RCs that are internally identified as the final version, for his thoughts.

Comment 2

[Brian Warner [:warner :bwarner]]

Yeah, I'm +0 on making almost-released code distinguishable from actually-released code. If it didn't complicate anything, I'd prefer that an rc1 be labled as such. In particular, I'd like the git sha1-based revision ID to be visible in the final product, so it's trivial to reconstruct the exact source code.

But that usually requires an extra build step in which some set of executable bits (which are the same in the final release as in the last rc) gets modified or wrapped with the version label. Jetpack currently doesn't have a build step like that, and it's not worth the complexity to me to add one.

I guess it also ties in to the social contract we're making with our releases. Most of the audience only ever sees 1.0, 1.1, etc: no alphas, betas, or rcs. Those folks have a fixed and simple mapping from their --version output to the source code. The next smaller demographic participates in testing of release candidates, and because there are fewer of them, I think it's more-or-less reasonable to ask them to pay closer attention to which build they're using: they have to use some external means to remember whether they built that XPI with 1.1rc1 or 1.1rc2 or 1.1 final.

(there's an even smaller demographic who participates in trunk development, and at that level all bets about version numbers are off: typically it will sit at something random like "1.0b6pre" until a release is made, and frequently it always just says "trunk". Fortunately these developers are careful to explain which git revision or whatever they're using whenever it matters. I'd love it if we could give these folks strong revision IDs too, but doing that correctly involves running a build-like step on each use of the tool, and that's even more complex).

Comment 3

[Wil Clouser [:clouserw]]

We were talking about this on IRC and it sounded like it was discussed before but no one knew why so I said I'd bring it up.  It sounds like this is a wontfix, so that's fine.

(In reply to Myk Melez [:myk] from comment #1)
> Umm, but we're only doing test runs, right?  So if we discover a bug that
> requires an RC2, can't we reset the test database and redo the test run? 

We can reset the database (which means resetting the filesystem too).  That currently takes around 24 hours with our infrastructure and deletes all the existing QA/testing data we have so it's not something we do too often.  Being able to move add-ons from 1.0 -> 1.1rc1 -> 1.1rc2 could save us time but yes, a final run should be done as close to the actual production steps as we can do it.

Thanks.