use release branches for unplanned releases

RESOLVED FIXED

Status

Socorro
General
P1
normal
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: rhelmer, Assigned: rhelmer)

Tracking

Trunk
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

7 years ago
Right now we have Hudson follow SVN trunk, which typically contains work slated for next release (e.g. after 1.7.5 is released, 1.7.6 will be in progress on trunk). Hudson follows trunk, and pushes builds to staging, which QA verifies.

Quite often, we need to release a patch for the current release, such as 1.7.5.1, 1.7.5.2, etc. Two examples from today are bug 630798 and bug 616343 (these are just config changes which are not appropriate for the override file, but we would also do an unplanned release for a critical bug, for instance).

We currently don't have any setup for testing or releasing these. In the past we've had IT make changes directly to production by patching, manually editing, or copying files, but we'd like to avoid both the time, but especially the potential for error.

Our current situation is that we check into trunk, and hope that staging is close enough. IT must either patch the fix in by hand, or we have to roll a new package by hand (not hard but error prone, see bug 630798 comment 15 for an example).

I propose the following:

1) use release branches for releases (created at release time)
2) make a new Hudson job that follows the latest release branch
3) have a separate staging environment, which has latest release + patch

This way, we get a Socorro package created automatically at checkin time, and it's automatically available on staging for QA to test (and point automated tests at). 

Even if we never take a change on the release branch, we will have an environment just like production for reproducing changes.
(Assignee)

Comment 1

7 years ago
(In reply to comment #0)
> Quite often, we need to release a patch for the current release, such as
> 1.7.5.1, 1.7.5.2, etc. Two examples from today are bug 630798 and bug 616343

I meant to say bug 631025 for the second one, although 616343 is an example of this same kind of thing :)
(Assignee)

Comment 2

7 years ago
Discussed trying this for 1.7.7 in https://wiki.mozilla.org/Breakpad/Status_Meetings/2011-Mar-09

Moved the proposal somewhere public:
https://wiki.mozilla.org/Socorro/Release_Branch_Proposal

We can rename and link to that from wiki.m.o/Socorro once we're happy with it.

At this point I'd suggest creating a 1.7.7 branch since we're past code freeze, and setting Hudson up to watch it in addition to trunk. This opens up trunk for 1.7.8 development.

Laura, what do you think? We could do this any time.
Status: NEW → ASSIGNED
Priority: -- → P1
(Assignee)

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 3

7 years ago
(In reply to comment #2)
> Discussed trying this for 1.7.7 in
> https://wiki.mozilla.org/Breakpad/Status_Meetings/2011-Mar-09
> 
> Moved the proposal somewhere public:
> https://wiki.mozilla.org/Socorro/Release_Branch_Proposal
> 
> We can rename and link to that from wiki.m.o/Socorro once we're happy with it.

We've starting doing this, I've moved this page to:
https://wiki.mozilla.org/Socorro/Release_Branch_Strategy

And linked from the appropriate section in https://wiki.mozilla.org/Socorro
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.