Closed Bug 711715 Opened 10 years ago Closed 10 years ago
gdata-provider versions should increase from release to beta to aurora to trunk
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.
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)
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.
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.
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)
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 :-)
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 #583062 - Attachment is obsolete: true
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+
Pushed to comm-central changeset 196773fc977c
Status: ASSIGNED → RESOLVED
Closed: 10 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.