gdata-provider versions should increase from release to beta to aurora to trunk

VERIFIED FIXED in 1.2

Status

defect
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: tonymec, Assigned: Fallen)

Tracking

Details

Attachments

(1 attachment, 5 obsolete attachments)

ATM, gdata-provider for Gecko 8 (found on AMO) bears version number 0.9 but the trunk version at ftp.m.o has only 0.9pre. This means that for people like me (using trunk mailer with extensions.strictCompatibility defaulted to false and extensions.checkCompatibility.nightly user-set to false) every "Check for Updates" in the addons manager proposes an "update" (which is in fact a downgrade) to Google Provider 0.9.

Each repo will need a distinct patch; I'll attach them shortly, starting with trunk.
this patch is for current trunk, it should land in comm-central before the upcoming merge, or in comm-aurora after it.
Attachment #582525 - Flags: review?(philipp)
I can't find from where to clone comm-aurora etc. (or is it simply comm-central but updated to a different branch?)

The corresponding patches for earlier versions should use the following version numbers:
0.11pre for Gecko 10 (current aurora, or beta after the upcoming merge)
0.10pre for Gecko 9 (current beta, or 0.10 in the release repo after the merge)
Attachment #582525 - Flags: feedback?(jh)
patch for Gecko 10 (current aurora). For beta after the upcoming merge, the "pre" in the version should perhaps be removed?

Approval request should be for _comm_ aurora. Patch touches only one file, install.rdf for Calendar::Providers:GData. No l10n import.
Attachment #582607 - Flags: review?(philipp)
Attachment #582607 - Flags: approval-mozilla-aurora?
Posted patch patch for Gecko 9 (current beta) (obsolete) β€” β€” Splinter Review
patch for current beta, or for release after the upcoming merge.

"pre" suffix removed from the version on the assumption that beta is "release-ready".

Approval request should be _comm_ beta. Only one Calendar file affected. No l10n import.
Attachment #582608 - Flags: review?(philipp)
Attachment #582608 - Flags: approval-mozilla-beta?
Sorry if I was unclear about this in the email. I'd rather have the current comm-aurora be 0.10, since then it somehow matches with the Thunderbird version (ie. Tb 10 + gdata 0.10).

To fix this all we need to do is push these patches after the merge, not now.

We shouldn't drop the pre anywhere other than a release branch. Since I'm doing manual releases there and I don't have to do so every 6 weeks, I'd rather do this manually on AMO.
(In reply to Philipp Kewisch [:Fallen] from comment #5)
> Sorry if I was unclear about this in the email. I'd rather have the current
> comm-aurora be 0.10, since then it somehow matches with the Thunderbird
> version (ie. Tb 10 + gdata 0.10).
> 
> To fix this all we need to do is push these patches after the merge, not now.

What about the current problem with gdata-provider 0.9 for Gecko 8, gdata-rovider 0.9pre for Gecko 9? Otherwise a match would be nice.

> 
> We shouldn't drop the pre anywhere other than a release branch. Since I'm
> doing manual releases there and I don't have to do so every 6 weeks, I'd
> rather do this manually on AMO.

I was going by the notion that current "beta" builds are actually what used to be called release-candidates, which is the rationale behind their already having (for Firefox, Thunderbird and SeaMonkey builds) the exact same version string that they will have once released.

To answer both problems, I'll make a new patch for Gecko 9 shortly, with gdata-provider version "0.9.1pre". Lowering the version of the AMO build raises its own problems, so I'd rather not do it.

If you agree, I am willing to patch the trunk version again every six weeks (on followup bugs to this one) to keep up with increasing Versions of Gecko trunk; the minVersion and maxVersion are already preprocessed by the builder machinery.
Attachment #582525 - Attachment description: patch for Gecko 11 (current trunk) → patch for Gecko 12 (trunk after imminent merge)
Attachment #582607 - Attachment description: patch for Gecko 10 (current aurora) → patch for Gecko 11 (current trunk, aurora after imminent merge)
Attachment #582608 - Attachment is obsolete: true
Attachment #582608 - Flags: review?(philipp)
Attachment #582608 - Flags: approval-mozilla-beta?
Attachment #583062 - Flags: review?(philipp)
Attachment #583062 - Flags: approval-mozilla-aurora?
Posted patch new patch for Gecko 9 (current beta) (obsolete) β€” β€” Splinter Review
Attachment #583066 - Flags: review?(philipp)
Attachment #583066 - Flags: approval-mozilla-beta?
Philipp, I don't know the merge schedule, but if you review these patches, then (if necessary after additional review- -> rewrite cycles, but I hope not too many) approve them or get them approved (do you have approval rights for Calendar-only fixes to comm-* ? It would seem logical but I don't rightly know) we can then decide where to land them when. I've now updated the patch titles in accordance with your comment #5 to simplify the task for whoever will do the actual hg push commands.
What do you say we automate it? This way we don't have to worry about anything at all :-)
Attachment #583148 - Flags: review?(mbanner)
Attachment #583148 - Flags: feedback?(antoine.mechelynck)
Comment on attachment 583148 [details] [diff] [review]
Automate version numbers

(In reply to Philipp Kewisch [:Fallen] from comment #10)
> Created attachment 583148 [details] [diff] [review]
> Automate version numbers
> 
> What do you say we automate it? This way we don't have to worry about
> anything at all :-)

At first (very cursory) glance, it seems OK, but I don't know Python well enough to be sure. I rely on Standard8 for the decisive review.

This patch seems to obsolete all four of mine: Philipp, maybe you should mark them as such?
Attachment #583148 - Flags: feedback?(antoine.mechelynck) → feedback+
Assignee: antoine.mechelynck → philipp
Status: ASSIGNED → NEW
Attachment #582525 - Attachment is obsolete: true
Attachment #582525 - Flags: review?(philipp)
Attachment #582607 - Attachment is obsolete: true
Attachment #582607 - Flags: review?(philipp)
Attachment #582607 - Flags: approval-mozilla-aurora?
Attachment #583062 - Flags: review?(philipp)
Attachment #583062 - Flags: approval-mozilla-aurora?
Attachment #583062 - Attachment is obsolete: true
Attachment #583066 - Attachment is obsolete: true
Attachment #583066 - Flags: review?(philipp)
Attachment #583066 - Flags: approval-mozilla-beta?
Yeah, just wanted to hear what you think before I do. The merge is happening this week, but with this automation we don't need to worry about gdata versions at all.

We might want to consider extra logic to fix the maxVersion of Tb/SM, but this needs to be done for Lightning too so no need to do it here.
Comment on attachment 583148 [details] [diff] [review]
Automate version numbers

Looks good to me.
Attachment #583148 - Flags: review?(mbanner) → review+
Status: NEW → ASSIGNED
Pushed to comm-central changeset 196773fc977c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4
Backported to releases/comm-aurora changeset f55e1e6dc97d
Target Milestone: 1.4 → 1.3
Backported to releases/comm-beta changeset 4ccf3fc691e3
Target Milestone: 1.3 → 1.2
Let us check the waterfalls and inspect the new install.rdf as they get built:

verified for comm-central linux-i686
extension version 0.13pre
Sunbird     minVersion 1.4a1 maxVersion 1.4a1
Thunderbird minVersion 8.0a1 maxVersion 12.0a1
SeaMonkey   minVersion 2.5a1 maxVersion 2.9a1

verified from comm-aurora linux-x86_64
extension version 0.12pre
Sunbird     minVersion 1.3a2 maxVersion 1.3a2
Thunderbird minVersion 8.0a1 maxVersion 11.0a2
SeaMonkey   minVersion 2.5a1 maxVersion 2.8a2

verified for comm-beta linux-i686
extension version 0.11pre
Sunbird     minVersion 1.2b1 maxVersion 1.2b1
Thunderbird minVersion 8.0a1 maxVersion 10.0
SeaMonkey   minVersion 2.5a1 maxVersion 2.7

I assume verification for one platform per branch is enough.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.