MozillaWiki

Bugzilla:Release Process: Difference between revisions

Bugzilla Discussion

Bugzilla:Release Process (view source)

Revision as of 03:29, 20 February 2018

1,547 bytes removed ,  20 February 2018
no edit summary
No edit summary
 
(10 intermediate revisions by 4 users not shown)
Line 3: Line 3:
== Security Releases ==
== Security Releases ==


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).
All security bugs should be triaged as soon as possible by the Bugzilla team. 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).


A high security bug would include (but is not limited to) data leakage (including CSRF/XSS attacks) or when the exploit is already publicly available (as was the case with bug 1036213). This would also include
A high security bug would include (but is not limited to) data leakage (including CSRF/XSS attacks) or when the exploit is already publicly available (as was the case with bug 1036213). This would also include
Line 14: Line 14:
== Version Numbers ==
== Version Numbers ==


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.
Major version increases (e.g. 5.0) reflect large, visible, and/or breaking changes.  These would include major features being removed or added, interfaces being changed, significant UI changes, 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.
Minor version increases (e.g. 5.2) reflect smaller 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.


Patch version increases (e.g. 5.2.1) usually reflect critical fixes, such as to security or other severe bugs.  While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime.  We may also occasionally release a patch version without critical fixes if there is a sufficiently large backlog of minor fixes, or for development snapshots (of an odd-numbered minor version).
Patch version increases (e.g. 5.2.1) usually reflect critical fixes, such as to security or other severe bugs.  While we generally wait until there is a critical fix to release a patch version, these versions may also contain other minor fixes committed in the meantime.  We may also occasionally release a patch version without critical fixes if there is a sufficiently large backlog of minor fixes, or for development snapshots (of an odd-numbered minor version).
Line 22: Line 22:
== When to Release ==
== When to Release ==


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.
We release approximately once per year with whatever is ready at the time. 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 version number will be determined at time of branching depending on the changes included, as per the section above.
 
== What to Release ==
 
As stated above, generally master will be branched approximately six months after the previous release, but there may be additional bugs to be fixed.  In August 2014, at the [[Bugzilla:Meetings:2014-08-27|public meeting]] and follow-up [https://groups.google.com/forum/#!topic/mozilla.dev.apps.bugzilla/2igVLzJ26h4 newsgroup discussion] we decided that the Target Milestone should be used to denote things that should be fixed before release, i.e., blockers, or bugs being actively worked on.  Release candidates should only be created after there are zero open bugs with the Target Milestone set to that release.  Furthermore, only the bug's assignee or a Bugzilla reviewer/approver should set or unset the Target Milestone.
 
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.


== Release Process Details ==
== Release Process Details ==
Line 42: Line 36:
* Release Notes: Point releases and rc1 versions need release notes. Each version being released needs a separate Release Notes bug filed. These bugs should block the first bug. For final releases of major versions, you need a "clean up release notes" bug. (Sample: bug 1042088)
* Release Notes: Point releases and rc1 versions need release notes. Each version being released needs a separate Release Notes bug filed. These bugs should block the first bug. For final releases of major versions, you need a "clean up release notes" bug. (Sample: bug 1042088)
* New Features Page (Release Candidates and Final Releases Only): Make this bug depend on the appropriate Release Notes bug. (Sample: bug 286278)
* New Features Page (Release Candidates and Final Releases Only): Make this bug depend on the appropriate Release Notes bug. (Sample: bug 286278)
=== Motivate People ===
Basically, just make it really easy to find and access all the bugs that need to be fixed for the release. I usually do this a few days after I file the above bugs.
This means:
* Do a search for blockers for the release, and make the query link into a tinyurl. When creating a tinyurl, make sure that no "order by" information is part of the URL so that you don't break people's LASTORDER cookies.
* Put that tinyurl at the very end of the topic line of the #mozwebtools IRC channel on irc.mozilla.org, with a brief explanation like "4.0.11 Blockers: tinyurl".
* Send out an email to developers@bugzilla.org explaining that we're releasing, and include the tinyurl. Having just one link in the email gets people to focus a bit more.
* If you are desperate: Send out an email to support-bugzilla with a tinyurl pointing to all bugs targeted at your release, sorted by Importance. Explain that you'd like some help, and link them also to the Contributor's Guide
* Do not include any sensitive security information in the email announcements yet.


=== Pre-Release ===
=== Pre-Release ===
Line 66: Line 48:


   Class:      Cross-site scripting
   Class:      Cross-site scripting
   Versions:    2.15 through 2.18rc3 and 2.19.1 (from cvs)
   Versions:    2.15 through 2.18rc3 and 2.19.1
   Description: It is possible to blah blah blah
   Description: It is possible to blah blah blah
                 And here are some details on how it can be made less bad...
                 And here are some details on how it can be made less bad...
Line 76: Line 58:
==== Determining Affected Versions ====
==== Determining Affected Versions ====


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.
It also can be a bit tricky to determine the earliest version affected by a security bug. git blame can help you find the place where the patched code was first introduced (that is, the code the Security bug is modifying) and which bug introduced it.


==== Getting it Reviewed ====
==== Getting it Reviewed ====


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.
Security Advisories must be reviewed by a member of the Bugzilla team. If you don't get a response after two or three days, check with people on IRC and get them to look at it.
 
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.


=== Release Notes ===
=== Release Notes ===


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.
The actual process of writing Release Notes is described in the [https://www.bugzilla.org/docs/releasenote.html Release Note Guide]. They should also be attached normally to the bug, and you should ask some reviewer to look over them.
 
They should also be attached normally to the bug, and you should ask some Documentation reviewer to look over them.


=== Web Site Updates ===
=== Web Site Updates ===


Check Out From CVS (needs to be put into Git)
In order to update the website, the first thing you have to do is check out its code from Git. Make sure you have checkin access on Github:
 
In order to update the website, the first thing you have to do is check out its code from CVS. The best place to do this is on landfill, because it already has the environment set up to be able to fully build the website. Make sure you have checkin access on cvs.mozilla.org.


The CVS info is:
  git@github.com:bugzilla/bugzilla.github.io


  CVSROOT=\:ext\:user%domain.com@cvs.mozilla.org\:/www
Or, if you don't have checkin access, but you want to work on the web site updates anyhow:
  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:
  https://github.com/bugzilla/bugzilla.github.io
 
  CVSROOT=\:pserver:anonymous@cvs-mirror.mozilla.org\:/www


==== Automatic Website Updater ====
==== Automatic Website Updater ====
Line 109: Line 82:
There is now a script that does most of the web site updates for a release, called bin/do-release.pl in the website checkout. You use it like this:
There is now a script that does most of the web site updates for a release, called bin/do-release.pl in the website checkout. You use it like this:


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


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.
That updates your local checkout as though you were going to do a release of 4.2.15, 4.4.10 and 5.0.1, with a security advisory where the lowest unfixed version being fixed was 4.2.14.


This script will update the files in your checkout appropriately for the release, and will also print a lot of messages like "** Remember to update some/file.html". Those "remember" messages are files that are not updated by the script, and will have to be updated by you. The updates that need to be done to those files are described below in the "Manual Website Updating" section below.
This script will update the files in your checkout appropriately for the release, and will also print a lot of messages like "** Remember to update some/file.html". Those "remember" messages are files that are not updated by the script, and will have to be updated by you. The updates that need to be done to those files are described below in the "Manual Website Updating" section below.
Line 123: Line 96:
Before we had the automatic updater script, we used to do all the website updates by hand. This section preserves the full instructions for how to update the website for a release, in case you need to understand exactly what the automatic script is doing, or in case you need to understand how to update one of the files that the script doesn't update.
Before we had the automatic updater script, we used to do all the website updates by hand. This section preserves the full instructions for how to update the website for a release, in case you need to understand exactly what the automatic script is doing, or in case you need to understand how to update one of the files that the script doesn't update.


* 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.
* 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 4.2.15, 4.4.10 and 5.0.1, and they all have a single Security Advisory, the security advisory goes into the 4.2.14/ directory.
* For each new release, create a "Release Info" page:
* For each new release, create a "Release Info" page:
** Create a directory in the releases/ directory for the new release.
** Create a directory in the releases/ directory for the new release.
Line 156: Line 129:


* Update Bugzilla/Constants.pm's BUGZILLA_VERSION variable.
* Update Bugzilla/Constants.pm's BUGZILLA_VERSION variable.
* 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 Bugzilla 4.4, you must also update docs/bugzilla.ent.tmpl. bz-ver, bz-date, 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.


=== Tag the Releases in Bzr, and Git ===
=== Tag the Releases in Bzr, and Git ===
Line 163: Line 135:
'''TODO''': This should all be a script at some point
'''TODO''': This should all be a script at some point


To tag a release in Bzr for the 4.0 branch:
To tag a release in Bzr for the 4.4 branch:


'''Note:''' bzr.bugzilla.org now resides on the community infrastructure and requires shell access to make the tags manually. Find dkl or justdave to get access. The BZR branches are located in /var/www/html/bzr.bugzilla.org/bugzilla.
'''Note:''' bzr.bugzilla.org now resides on the community infrastructure and requires shell access to make the tags manually. Find dkl or justdave to get access. The BZR branches are located in /var/www/html/bzr.bugzilla.org/bugzilla.


   bzr tag bugzilla-4.0.14
   bzr tag bugzilla-4.4.11
   bar tag --force bugzilla-stable
   bar tag --force bugzilla-stable


To tag a release in Git for the 4.0 branch:
To tag a release in Git for the 4.4 branch:
    
    
   git checkout 4.0
   git checkout 4.4
   git tag bugzilla-4.0.14 <commitid>
   git tag bugzilla-4.4.11 <commitid>
   git tag release-4.0.14 <commitid>
   git tag release-4.4.11 <commitid>
   git push origin bugzilla-4.0.14
   git push origin bugzilla-4.4.11
   git push origin release-4.0.14
   git push origin release-4.4.11
   git push --delete origin bugzilla-4.0.14 (to remove a tag if needed)
   git push --delete origin bugzilla-4.4.11 (to remove a tag if needed)


'''Note:''' Once 5.0 is released, we will only be using the release-x.x.x tag form
'''Note:''' Since 5.0, we only use the release-x.x.x tag form for 5.0 and future releases.
for 5.0 and future releases.


Creating stable release branch in git initially:
Creating stable release branch in git initially:


   git checkout 4.0
   git checkout 4.4
   git branch release-4.0-stable <commitid>
   git branch release-4.4-stable <commitid>
   git push origin release-4.0-stable
   git push origin release-4.4-stable


Updating stable release branch after bumping version number step:
Updating stable release branch after bumping version number step:


   git checkout release-4.0-stable
   git checkout release-4.4-stable
   git merge origin/release-4.0.14
   git merge release-4.4.11
   git push
   git push


Line 200: Line 171:
For building tarballs for 4.2.x and newer:
For building tarballs for 4.2.x and newer:


   ./build.pl 4.2.10
   ./build.pl 4.2.15
   ./build.pl 4.4.5
   ./build.pl 4.4.10
   ./build.pl 4.5.5
   ./build.pl 5.0.1


==== Make the Diff Files ====
==== Make the Diff Files ====
Line 214: Line 185:
==== Post the Files ====
==== Post the Files ====


Using sftp or scp, upload the tarballs and .diff.gz files to stage.mozilla.org, to the /pub/mozilla.org/webtools directory.
Mozilla recently migrated specific files on ftp.mozilla.org to be served from Amazon S3 buckets. In order to upload the tar files and diffs to S3, you will need to have access keys assigned to your account. dkl and justdave currently have access keys so either of them can upload the files.
 
You will need to download and install the aws-cli client from github.
 
http://docs.aws.amazon.com/cli/latest/userguide/installing.html#install-bundle-other-os
 
Create an .aws directory in your user's home directly.
 
Generate an .aws/credentials file containing your access keys assigned to you.
 
  [default]
  aws_access_key_id=<ACCESS_KEY>
  aws_secret_access_key=<SECRET_ACCESS_KEY>
 
Generate an .aws/config file that specifies the region desired.
 
  [default]
  region=us-east-1
  output=json
 
To copy a file to S3 available for download. Need to do for each file:
 
  $ aws s3 cp <local_file> s3://net-mozaws-prod-delivery-contrib/pub/webtools/
 
The file can then be accessed by the general public at the same URL as before (over https only):
 
  https://ftp.mozilla.org/pub/mozilla.org/webtools/<file>
 
As a shortcut to copy all of the gz files, one after the other:
 
  $ for i in `ls *.gz`; do aws s3 cp $i s3://net-mozaws-prod-delivery-contrib/pub/webtools/; done
 
To remove a file from S3:
 
  $ aws s3 rm s3://net-mozaws-prod-delivery-contrib/pub/webtools/<remote_file>
 
To list the current files in S3:
 
  $ aws s3 ls s3://net-mozaws-prod-delivery-contrib/pub/webtools


Remember to fix the bugzilla-LATEST and bugzilla-STABLE symlinks, if necessary.
To copy a file on S3 to another name. This needs to be done to mimic the old symlinks for bugzilla-STABLE.tar.gz and bugzilla-LATEST.tar.gz:


Also verify that the uploaded files are world readable so that downloads will work properly.
  $ aws s3 cp s3://net-mozaws-prod-delivery-contrib/pub/webtools/<src_file> s3://net-mozaws-prod-delivery-contrib/pub/webtools/<dest_file>


=== Check-In the Website Updates ===
=== Check-In the Website Updates ===
Line 243: Line 252:
The Security Advisory is sent to:
The Security Advisory is sent to:


* BugTraq
* [http://www.securityfocus.com/archive/post/1 BugTraq]
* announce@bugzilla.org
* announce@bugzilla.org
* support-bugzilla@lists.mozilla.org
* support-bugzilla@lists.mozilla.org
Line 255: Line 264:
Make sure that you put [ANN] at the beginning of the Subject line. List the fixed versions.
Make sure that you put [ANN] at the beginning of the Subject line. List the fixed versions.


    [ANN] Release of Bugzilla 5.0.1, 4.4.10, and 4.2.15
  [ANN] Release of Bugzilla 5.0.1, 4.4.10, and 4.2.15


Send it to:
Send it to:
Line 266: Line 275:
=== Update updates.bugzilla.org ===
=== Update updates.bugzilla.org ===


Update bugzilla-update.xml on landfill so that the notification system will detect new releases.
Update bugzilla-update.xml on updates.bugzilla.org so that the notification system will detect new releases.


   ssh dlawrence@updates.bugzilla.org
   ssh dlawrence@updates.bugzilla.org
DaveLawrence
637

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1094710...1189163"