Closed Bug 420947 Opened 17 years ago Closed 17 years ago

patcher creates directories with a pretty version when it should use the short version

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

Details

Attachments

(4 files, 3 obsolete files)

We hit this in Firefox 3 Beta 4, it appears to be fallout from bug 410006. When creating update snippets patcher creates a directory like this: /opt/aus2/incoming/3/Firefox/3 Beta 3 When it should really be creating: /opt/aus2/incoming/3/Firefox/3.0b3 Apparently, this only happens when the oldVersion, as the patch in bug 410006 was landed before the Beta 3 release and did not cause problems with it. Patcher should be fixed to only use the 'version' in a <release> subsection when it needs something pretty. Any other time it should simply use the subsection name. Here's an example <app> <Firefox> ... ... &nbsp;&nbsp;<release> &nbsp;&nbsp;&nbsp;<3.0b3> &nbsp;&nbsp;&nbsp;&nbsp;version 3 Beta 3 &nbsp;&nbsp;&nbsp;</3.0b3> &nbsp;&nbsp;</release> ... ... </Firefox> </app> In this case, '3 Beta 3' should be used as the pretty string, and '3.0b3' for everything else. I'm working on a patch for this.
Ugh, stupid Bugzilla. <app> <Firefox> ... ... <release> <3.0b3> version 3 Beta 3 </3.0b3> </release> ... ... </Firefox> </app>
Priority: -- → P2
From discussion on IRC: Nick suggested using a 'prettyVersion' in the patcher config and leaving 'version' for what it was originally intended for. This will require patcher and Bootstrap patches. We should also go through the patcher configs and make sure there are no 'version' properties with a pretty version in them.
I've got a fix in testing right now, I'll be posting patches tomorrow.
I looked through the MozAUS* and patcher2.pl code and this seems to be the only place this change is needed. I've run patcher locally and it appears to generate good snippets, I'll be attaching them in a moment. I will also be attaching updated patcher configs.
Attachment #307460 - Flags: review?(nrthomas)
Attached file complete.txt on beta channel (obsolete) (deleted) —
The <rc> section of this config did not contain 'beta'
Attached file partial.txt on betatest channel (obsolete) (deleted) —
betatest _was_ in the <rc> section.
Attachment #307461 - Attachment description: complete.txt generated → complete.txt on beta channel
I'm not 100% sure if this is needed or not, I believe prettyVersion will only be used on the current release, not the old one. But just in case, I added it to the latest releases on the 1.8 and 1.9 patcher configs. After reading MozAUSConfig.pm a bit more I'm quite certain we won't need these on even older releases. I purposely did not touch major update configs.
Attachment #307463 - Flags: review?(nrthomas)
This is pretty trivial. The 'version' is set to the be same as the 'extension-version', like before. And 'prettyVersion' has been added. Now that GetVersion() exists we can just use it to extrapolate a pretty version (which I probably should've done when I added that function in the first place).
Attachment #307464 - Flags: review?(rhelmer)
Attachment #307464 - Flags: review?(rhelmer) → review+
This patch contains minor changes to MozAUSConfig.pm, which add a 'prettyAppv' to the data structure that patcher2.pl uses to generate updates. There are larger changes to patcher2.pl that do the following (in a few places): Add a 'prettySnippetToAppVersion' wherever there is a 'snippetToAppVersion'. 'snippetToAppVersion' was previously used to set the appv in the snippet as well as provide progress on the command-line. In this version 'prettySnippetToAppVersion' performs the former, while snippetToAppVersion does the latter. I was going to simply redefine 'snippetToAppVersion' as 'prettyVersion', but that made the command line output pretty ugly.
Attachment #307460 - Attachment is obsolete: true
Attachment #307546 - Flags: review?(nrthomas)
Attachment #307460 - Flags: review?(nrthomas)
This is a diff of the aus2 and aus2.test directories using both unmodified patcher code, and patcher patched with attachment 307546 [details] [diff] [review]. As far as I can tell, only the appv is changed.
Attachment #307461 - Attachment is obsolete: true
Attachment #307462 - Attachment is obsolete: true
Comment on attachment 307546 [details] [diff] [review] [checked in] try it in a different way r+, thanks for making the more involved patch. I did some extra testing with 2.0.0.x, adding prettyVersion's to the 2.0.0.11 and the 2.0.0.12 blocks in the moz18-branch-patcher.cfg. That induces no changes except where it should, obviously a quick inspection rather than a complete one, 15000 files :-(
Attachment #307546 - Flags: review?(nrthomas) → review+
Attachment #307463 - Flags: review?(nrthomas) → review+
Comment on attachment 307463 [details] [diff] [review] [checked in] 1.8 and 1.9 patcher configs, update with prettyVersion Checking in moz18-branch-patcher2.cfg; /cvsroot/mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg,v <-- moz18-branch-patcher2.cfg new revision: 1.9; previous revision: 1.8 done Checking in moz19-branch-patcher2.cfg; /cvsroot/mozilla/tools/patcher-configs/moz19-branch-patcher2.cfg,v <-- moz19-branch-patcher2.cfg new revision: 1.21; previous revision: 1.20 done
Attachment #307463 - Attachment description: 1.8 and 1.9 patcher configs, update with prettyVersion → [checked in] 1.8 and 1.9 patcher configs, update with prettyVersion
Comment on attachment 307546 [details] [diff] [review] [checked in] try it in a different way Checking in MozAUSConfig.pm; /cvsroot/mozilla/tools/patcher/MozAUSConfig.pm,v <-- MozAUSConfig.pm new revision: 1.17; previous revision: 1.16 done Checking in patcher2.pl; /cvsroot/mozilla/tools/patcher/patcher2.pl,v <-- patcher2.pl new revision: 1.30; previous revision: 1.29 done I'm going to retag with UPDATE_PACKAGING_R1_1 and bump the staging machines to that. If that goes well, we can bump the production ones later.
Attachment #307546 - Attachment description: try it in a different way → [checked in] try it in a different way
Quick correction: will be tagging with UPDATE_PACKAGING_R2
Comment on attachment 307464 [details] [diff] [review] [checked in] bootstrap changes to support patcher changes Checking in Bootstrap/Step/PatcherConfig.pm; /cvsroot/mozilla/tools/release/Bootstrap/Step/PatcherConfig.pm,v <-- PatcherConfig.pm new revision: 1.19; previous revision: 1.18 done Checking in configs/fx-moz19-bootstrap.cfg; /cvsroot/mozilla/tools/release/configs/fx-moz19-bootstrap.cfg,v <-- fx-moz19-bootstrap.cfg new revision: 1.18; previous revision: 1.17 done Checking in configs/fx-moz19-staging-bootstrap.cfg; /cvsroot/mozilla/tools/release/configs/fx-moz19-staging-bootstrap.cfg,v <-- fx-moz19-staging-bootstrap.cfg new revision: 1.13; previous revision: 1.12 done
Attachment #307464 - Attachment description: bootstrap changes to support patcher changes → [checked in] bootstrap changes to support patcher changes
Alright, I've created UPDATE_PACKAGING_R2 following the instructions here: https://bugzilla.mozilla.org/show_bug.cgi?id=411235#c10 cvs co -r UPDATE_PACKAGING_R1 mozilla/client.mk cd mozilla make -f client.mk MOZ_CO_PROJECT=all checkout cvs up -A tools/update-packaging cvs up -AdP tools/release cvs up -AdP tools/patcher cvs -q tag UPDATE_PACKAGING_R2 2>&1 | tee ../tag.log grep -v '^T' ../tag.log cvs tag -b UPDATE_PACKAGING_R2_minibranch client.mk cvs up -r UPDATE_PACKAGING_R2_minibranch client.mk edited client.mk, bumped to UPDATE_PACKAGING_R2 commited client.mk Checking in client.mk; /cvsroot/mozilla/client.mk,v <-- client.mk new revision: 1.314.2.1.2.1.2.1; previous revision: 1.314.2.1.2.1 done re-tagged cvs -q tag UPDATE_PACKAGING_R2 client.mk W client.mk : UPDATE_PACKAGING_R2 already exists on version 1.314.2.1.2.1 : NOT MOVING tag to version 1.314.2.1.2.1.2.1 cvs -q tag -F UPDATE_PACKAGING_R2 client.mk
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: