Bugzilla:Release Process: Difference between revisions

All security bugs to be triaged one business day by a Assistant Project Leader or Project Leader. Along with the Mozilla Security Team, it should be determined if the issue is valid, and the severity (the sec-low, sec-moderate and sec-high keywords is normally used for this).

Major version increases (e.g. 5.0) reflect large, visible, and/or breaking changes.  These would include features being removed, interfaces being changed, dependencies being updated, significant UI changes, major new features, etc.

Minor version increases (e.g. 5.2) reflect noncritical bugfixes, small new features, and other nonbreaking changes.  These would include additions and/or backward-compatible changes to interfaces, support for new technologies or platforms, and general improvements and fixes.  Note that official releases will always have an even-numbered minor version (e.g. 5.0, 5.2, 5.4); odd numbers are reserved for development releases.  This applies only to the minor version number.

In [[Bugzilla:Meetings:2014-05-28|May 2014]] we decided to try to release approximately every 6 months with whatever is ready at the time. This gets new features out the door more quickly.  Branching should be done when master is relatively stable, but sometimes branching with known bugs is acceptable if it allows other large, potentially unstable features to land (for the next release).  If there are bugs related to new features in the release branch, the feature should be backed out of the release branch (if it's very recent), or fixes should be committed to both the release branch and master.  Bugs blocking release should be denoted with a blocking<version> flag, e.g. blocking5.0.

The version number will be determined at time of branching depending on the changes included, as per the section above.  Note that this means we may have back-to-back major releases.

 

 

 

The existing policy of having approvers set or update the Target Milestone, if necessary, on bugs that are committed before an upcoming release continues unchanged.

   Versions:    2.15 through 2.18rc3 and 2.19.1 (from cvs)

It also can be a bit tricky to determine the earliest version affected by a security bug. What I do is use Loggerhead's "Files" interface to find the place where the patched code was first introduced. (That is, the code the Security bug is modifying.) Then, by looking at the Changes log in Loggerhead, you can match that up with the dates on the Release Information page.

Security Advisories get sent to security@bugzilla.org for review. Allow at least two or three days for the members of the list to respond.

 

If you don't get a response after three or four days, that probably means the advisory is fine. But still check with people on IRC and get them to look at it.

The actual process of writing Release Notes is described in the Release Noting Guide. The important thing to remember about Release Notes is that they should be sent to reviewers@bugzilla.org for comment. Give the list about two days to respond.

 

They should also be attached normally to the bug, and you should ask some Documentation reviewer to look over them.

Check Out From CVS (needs to be put into Git)

 

The CVS info is:

  CVSROOT=\:ext\:user%domain.com@cvs.mozilla.org\:/www

  cvs -z3 checkout bugzilla-org

Or, if you don't have checkin access, but you want to work on the web site updates anyhow, the CVSROOT for anonymous access is:

  CVSROOT=\:pserver:anonymous@cvs-mirror.mozilla.org\:/www

bin/do-release.pl --security=3.2.6 3.7.1 3.6.1 3.4.7 3.2.7

That updates your local checkout as though you were going to do a release of 3.7.1, 3.6.1, 3.4.7, and 3.2.7, with a security advisory where the lowest unfixed version being fixed was 3.2.6.

* Create a directory for the Security Advisory. The directory is always numbered by the lowest unfixed version that is being fixed. For example, if you release versions 2.16.9, 2.18.1, and 2.19.3, and they all have a single Security Advisory, the security advisory goes into the 2.16.8/ directory.

* Update docs/en/xml/Bugzilla-Guide.xml. bz-ver, bz-date, bz-nextver, and current-year need to be updated. You may also have to update landfillbase if you just branched.

* For 4.3 and newer, instead of docs/en/xml/Bugzilla-Guide.xml you need to update docss/bugzilla.ent.tmpl.

To tag a release in Bzr for the 4.0 branch:

   bzr tag bugzilla-4.0.14

To tag a release in Git for the 4.0 branch:

   git checkout 4.0

   git tag bugzilla-4.0.14 <commitid>

   git tag release-4.0.14 <commitid>

   git push origin bugzilla-4.0.14

   git push origin release-4.0.14

   git push --delete origin bugzilla-4.0.14 (to remove a tag if needed)

'''Note:''' Once 5.0 is released, we will only be using the release-x.x.x tag form

for 5.0 and future releases.

   git checkout 4.0

   git branch release-4.0-stable <commitid>

   git push origin release-4.0-stable

   git checkout release-4.0-stable

   git merge origin/release-4.0.14

   ./build.pl 4.2.10

   ./build.pl 4.4.5

   ./build.pl 4.5.5