Closed Bug 493955 Opened 16 years ago Closed 15 years ago

Remove module.ver logic from version-bump.pl

Categories

(Release Engineering :: General, defect, P3)

x86
Windows Server 2003
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kairo, Unassigned)

References

Details

(Whiteboard: [automation])

Attachments

(1 file, 1 obsolete file)

Now that we don't need to bump versions directly in module.ver any more, we can remove the logic for that from http://hg.mozilla.org/build/tools/file/34afe709615b/release/version-bump.pl#l75 and other places in this file. Ben says he wants to run through a few releases before that and make sure nothing breaks, though.
Going to put this in Future for now.
Blocks: 478420
Component: Release Engineering → Release Engineering: Future
Component: Release Engineering: Future → Release Engineering
Priority: -- → P2
Attached patch untested patch (obsolete) — Splinter Review
We're not using the module.ver bits anymore, so should be safe. I'll try it out tomorrow.
Comment on attachment 390312 [details] [diff] [review] untested patch This is tested and ready for review
Attachment #390312 - Flags: review?(nthomas)
Assignee: nobody → bhearsum
Comment on attachment 390312 [details] [diff] [review] untested patch We still need this for Firefox 3.0, me thinks.
Attachment #390312 - Flags: review?(nthomas) → review-
Nick, is Firefox 3.0 running off the hg build tools?
Yes, indeed. Back to the future for you, bug 493955.
Assignee: bhearsum → nobody
Component: Release Engineering → Release Engineering: Future
KaiRo, version-bump.pl was originally in the Bootstrap framework for Fx3.0 and older releases. We separated it out to reuse it for mercurial-based releases.
(In reply to comment #7) > KaiRo, version-bump.pl was originally in the Bootstrap framework for Fx3.0 and > older releases. We separated it out to reuse it for mercurial-based releases. Sure, my point was that if this copy of it isn't used for Fx3.0 (and only a copy in CVS is) then we can safely remove it from this copy and leave it in on the CVS copy. Of course, if the release process for 3.0 also uses the copy from hg then we need to keep it until we EOL that series.
We split the code out of Bootstrap to prevent duplication, so having separate copies in CVS and hg goes against that. They both use hg.mozilla.org/build/tools.
(In reply to comment #9) > They both use > hg.mozilla.org/build/tools. OK, then we need to wait for 1.9.0 EOL before we remove this. Good to know.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: P2 → P3
Whiteboard: [automation] waiting for fx-3.0 and tb-2.0 EOL
Comment on attachment 390312 [details] [diff] [review] untested patch How about now?
Attachment #390312 - Flags: review- → review?(nrthomas)
(FF2.0+TB3.0 EOLed)
Whiteboard: [automation] waiting for fx-3.0 and tb-2.0 EOL → [automation]
(In reply to comment #13) > (FF2.0+TB3.0 EOLed) You mean FF3.0 and TB2.0, actually (as those were the ones named in whiteboard until you removed it in that comment). ;-)
Attached patch Unrotted patchSplinter Review
The code changed a bit in (eg bug 500471) so here's the unrotted patch that gets my r+ and landing. http://hg.mozilla.org/build/tools/rev/204880f4c78c
Attachment #390312 - Attachment is obsolete: true
Attachment #456805 - Flags: review+
Attachment #456805 - Flags: checked-in+
Attachment #390312 - Flags: review?(nrthomas)
Status: NEW → RESOLVED
Closed: 15 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: