From e623c920e9727ab76facd7fdecf36f5e0cdf7552 Mon Sep 17 00:00:00 2001 From: Rene Rivera Date: Sun, 2 Dec 2007 04:06:28 +0000 Subject: [PATCH] Remove outdated release procedures, and move content to wiki. Content moved to and . (fixes #1366 #1367) [SVN r41565] --- release_mgr_checklist.html | 276 ------------------------------------- release_procedures.htm | 213 ---------------------------- 2 files changed, 489 deletions(-) delete mode 100644 release_mgr_checklist.html delete mode 100644 release_procedures.htm diff --git a/release_mgr_checklist.html b/release_mgr_checklist.html deleted file mode 100644 index 7cfaa1f..0000000 --- a/release_mgr_checklist.html +++ /dev/null @@ -1,276 +0,0 @@ - - - - - - - - -Release Manager's Checklist - - - - - - - - - - - - - -
- boost.png (6897 bytes)HomeLibrariesPeopleFAQMore
- - -

Release Manager's Checklist

- -

Introduction
-Pre-release activities
-CVS Branch for release
-CVS Release
-Distribution

- -

Introduction

-

Historically, items on this checklist were accomplished by scripts written -in Perl, Python, Bash, C++, and as Windows command files, or by point-and-click -on a FrontPage or other GUI based program. Long term the plan is to move as much -as possible of these to C++, as -the one language all Boost developers are comfortable with.

-

Pre-release activities

-
    -
  • After discussion on the main list, post the release schedule.
    - 
    • -
  • Verify the root/index.htm, root/boost/version.hpp, root/Jamfile.v2 and - root/Jamrules - release numbers are correct and agree.
    - 
    • -
  • Verify via jamboost@yahoogroups.com - that bjam pre-built executables up-to-date.
    - 
    • -
  • Remove the oldest "Latest News" from root/index.htm.
    - 
    • -
  • For each new library added this release:
    • -
-
-
    -
  • Verify root/index.htm Latest News entry has been made and reads well.
    - 
    • -
  • Verify root/libs/libraries.htm entry has been made, both in the - alphabetic list and in the category lists.
    - 
    • -
  • Verify the root/libs/xxx directory contains an index.htm or index.html - file; either the main docs or a redirection to the main docs. To do: - automate this.
    - 
    • -
  • Skim read the primary docs pages to make sure they meet Boost - requirements and guidelines. Don't leave this until too late; it has - turned up lots of issues in the past.
    - 
    • -
  • Generate the header dependency table and update the CVS. To do: - coordinate with John Maddock's new dependency tools.
    • -
-
-
    -
  • Monitor - - http://boost.sourceforge.net/regression-logs/inspection_report.html to - verify problems are actively being reduced. Make sure none of the problems are - in files the release manager is responsible for.
    - 
    • -
  • Monitor regression tests (http://boost.sourceforge.net/regression-logs) - to verify that errors are actively being reduced or accounted for on key - platforms and compilers.
    - 
      -
    • Boost errors are being actively worked on by library maintainers.
      • -
    • Compiler or standard library errors are at least identified, and - preferably reported to the supplier.
      • -
    • No errors remain uninvestigated or unclassified.
      - 
      • -
    -
    • -
  • Monitor the developer and user mailing lists to verify that all posted - patches are being applied, rejected, or otherwise dealt with.
    - 
    • -
  • Monitor the developer and user mailing lists, and the SourceForge bug - tracker, to verify that all posted bug reports are being investigated, fixed, - rejected, or otherwise dealt with.
    - 
    • -
  • Monitor CVS commits to verify that all the expected and/or promised - content actually gets committed. Try to get developers to avoid last minute - commits of major changes.
    • -
-

CVS Branch for release

-
    -
  • Pre-release activities complete enough to justify branch-for-release?
    - 
    • -
  • Everybody happy?
    - 
    • -
  • Branch for release:
      -
    • Tag the main trunk  merged_to_RC_n_n_n.
      • -
    • Branch the main trunk with the tag RC_n_n_n.
      - 
      • -
    -
    • -
  • Post notice on main list. Remind developers that fixes which apply - to both Main Trunk and Branch have to be committed separately to both.
    • -
-

CVS Release

-
    -
  • Pre-release activities all complete?
    - 
    • -
  • Post notice to make sure all developers ready.
    - 
    • -
  • Tag: WinCVS: Select site, then tag (Modify|Create tag..., toolbar T on doc). New - tag name: Version_1_21_2 (or whatever). If prior release failed, select - "overwrite existing tags with the same name".
    • -
-

Distribution

-

These procedures are given for a particular release manager's machine. The -plan is to replace them with more generic procedures over time.

-
    -
  • Create folders for export:
    -
    -    c:\boost\boost_1_28_0
    -    c:\boost\temp\boost_1_28_0
    -
    - Note that several batch files assume these locations and naming schemes.
    - 
    • -
  • Export Win32 distribution: WinCVS | Remote | Checkout Module
    -
    - Checkout settings: module name and path on the server: boost, local folder to - checkout to: c:\boost\boost_1_28_0
    - [for 1.29.0 export, put everything in a boost_1_29_0/boost subdirectory.  - Experiments with 1.30.0 tried boost/boost as the path on server, but that just - resulted in getting the boost header subdirectory only.]
    -
    - Checkout options: (check) By revision/tab/branch: Version_1_28_0, (check) Do - not create CVS directories (export)
    -
    - This results in the follow command: cvs -z9 export -r Version_1_28_0 boost (in - directory C:\boost\boost_1_28_0)
    -
    - (takes about ten minutes)
    -
    - (rename boost-root if needed !!!!!!!!!!!!!!!!!!!)
    - 
    • -
  • Export Unix distribution: similar to above, except target is c:\boost\temp\boost_1_28_0 - and set global for UNIX nl.
    -  
    • -
  • !!!!!! VERY IMPORTANT: WinCVS | Set Preferences | Global back to non-UNIX nl. - !!!!!!!!!!!!!!!
    - 
    • -
  • Add regression results web pages into package (new in 1.33 so this is just a shot at the process - jeff)
    - download all the regression results from website (may need meta-comm help on this)
    - unpack the regression results into tools/regression/latest_release
    -
    - -
    • -
  • General ZIP and TAR.GZ files
    -
    - n_n_n is 1_28_0 or whatever
    -
    - cd \boost
    - boost_zip 1_21_2 (creates zip.log)
    - boost_tar_gz 1_21_2
    - bash
    -    - gunzip -c boost_1_21_2.tar.gz | bzip2 > boost_1_21_2.tar.bz2
    -    exit
    -  
    • -
  • Upload and unpack the .zip release candidate to a SourceForge web services - sub-directory. Post a message to the main list asking developers to check - contents. (Daniel Frey has volunteered to help check).
    - 
    • -
  • Upload files for SourceForge release incoming directory using WS_FTP Pro
      -
    • Start keep_isdn_awake
      • -
    • Connection: SourceForge Release Upload | connect
      • -
    • Select Local system: c:\boost
      • -
    • Select Remote system: /incoming
      • -
    • Drag-and-drop the three release files from Local system to Remote system
      • -
    • Disconnect
      • -
    • Stop keep_isdn_awake
      - 
      • -
    -
    • -
  • Complete the SourceForge - - release procedure.
      -
    • Admin | File Releases | Add Release for package name boost
      • -
    • New release name: 1.21.2 | create this release
      • -
    • Step 1: paste in release notes (in HTML). Be sure to note difference - between .zip and .gz/bz2 files. Submit/Refresh
      • -
    • Step 2: Check appropriate files. Add Files and/or Refresh View
      • -
    • Step 3: For each file, select Processor and File Type, Update/Refresh
      • -
    • Setp 4: Email Release Notice: I'm sure. Send Notice.
      • -
    • Wait up to 30 minutes.
      • -
    • Check SourceForge release page and release notes with web browser.
      - 
      • -
    -
    • -
  • Consider putting up a temporary "Update in progress" root/index.html - during site update
    - 
    • -
  • Update the web site:
    cd ...\boost_1_28_0
-tar -cf site.tar *
-bzip2 -k site.tar
-
-dir site.tar.bz2
-pscp site.tar.bz2 beman_dawes@shell1.sourceforge.net:/home/groups/b/bo/boost/htdocs/
-
-keep_idsn_awake in another window.
-
-c:\bgd\util\putty\plink.exe beman_dawes@shell.sourceforge.net
-cd /home/groups/b/bo/boost/htdocs
-pwd
-ls -l site.tar.bz2
-
-rm -fr boost
-rm -fr doc
-rm -fr libs
-rm -fr more
-rm -fr people
-rm -fr status
-rm -fr tools
-bunzip2 -kc site.tar.bz2 | tar -x 
-ls
-exit
-
-stop keep_isdn_awake
    -
    • -
  • Check actual www.boost.org site with - browser. Look at a bunch of files that should have been updated to make sure - the updates actually "took".
    - 
    • -
  • Post a message announcing the release and recapping "Latest News".  - Post as separate messages to: boost, boost-announce, boost-users, - comp.lang.c++.moderated, - c++std-news@research.att.com
    - 
    • -
  • Using the SourceForge shell services (sf_shell_svc.bat), cd /home/groups/b/bo/boost/htdocs, - and rename regression tests as necessary.
    - 
    • -
  • Burn "Key Directories" CD for off-site backup.
    - 
    • -
  • Make sure CVS working copy is updated to main branch!
    - 
    • -
  • Ready root/index.htm, root/boost/version.hpp, root/Jamfile.v2 and - root/Jamrules for the - next release and commit to CVS so developers have a place to add "Latest news" - blurbs.
    - 
    • -
  • Delete obsolete files from yahoogroups files section.
    • -
-
-

Revised: -21 November, 2005

-

© Copyright Beman Dawes 2001

- -

Distributed under the Boost Software License, Version 1.0. (See accompanying -file LICENSE_1_0.txt or copy at -http://www.boost.org/LICENSE_1_0.txt)

- - - - diff --git a/release_procedures.htm b/release_procedures.htm deleted file mode 100644 index aefa80a..0000000 --- a/release_procedures.htm +++ /dev/null @@ -1,213 +0,0 @@ - - - - - - - - -Release Procedures - - - - - - - - - - - - - -
- boost.png (6897 bytes)HomeLibrariesPeopleFAQMore
- - -

Boost Release Procedures

-

Introduction
-Procedure Overview
-Procedures for Developers
-Procedures for the Release Manager
-FAQ
-Acknowledgements

-

Introduction

-

Each release of Boost software is overseen by a release manager, who -coordinates release activities via the Boost mailing list, as well as performing -the detailed procedures for the release.

-

Boost developers assist the release manager by reviewing regression test -logs, and committing fixes to CVS.

-

Release Procedure Overview

-
    -
  • Discussion on the main Boost mailing list to determine the target date for - release candidate branch and tag of the CVS main trunk.
    - 
    • -
  • Release manager performs release candidate branch, and also tags the - branch point in main trunk.
    - 
    • -
  • Regression tests run on release candidate branch.
    - 
    • -
  • Developers fix problems, test, and commit fixes. See below for details.
    - 
    • -
  • Repeat previous two steps until release manager is satisfied.
    - 
    • -
  • Release manager rolls out the actual release.
    • -
-

Release Procedures for Developers

-
    -
  • As the release candidate branch date approaches (as announced on the main - mailing list), bring the main trunk CVS files you are responsible for into a - stable state.
    - 
    • -
  • If you know of changes in either your code or its dependencies, start - checking regression test results to ensure your tests still pass.  Don't - necessarily wait for the initial release tagging.
    - 
    • -
  • After the release manager announces that the release candidate branch has - occurred, check the latest regression test results to be sure - your tests haven't broken.
    - 
    • -
  • Developers can continue working on main trunk code changes after - the release candidate branch has occurred. There is no need to wait until the release - itself.  - Modified files committed to CVS on the main trunk will not be included in the release unless the - developer explicitly commits the changes to the release candidate branch.
    - 
    • -
  • If specific to the release candidate only, the fixes should be committed - directly to the release candidate branch. In the more common case of fixes - which apply to both the main trunk and the release branch, the fixes are best - made to the main trunk, and then merged into the release candidate branch. See - FAQ for tag rationale.
    -
    - After a fix has been committed to the main trunk, here is a - typical procedure (assuming the release candidate branch is named RC_1_26_2) - to merge the fixed main trunk into the release candidate branch:
    • -
-
-
    -
  • Command Line CVS:
    • -
-
-
    -
  • Fixed code is committed to main branch
    - 
    • -
  • Switch to the release candidate branch -
    - cvs update -r RC_1_26_2
    -
    • -
  • Merge changes in a trunk since previous merge to branch -
    -
    cvs update -jmerged_to_RC_1_26_2 -jHEAD buggycode.hpp
- --> RCS file: /cvsroot/boost/.../buggycode.hpp,v
- -->    retrieving revision 1.4
- -->    retrieving revision 1.6
- -->    Merging differences between 1.4 and 1.6 into buggycode.hpp
    -
    -
    • -
  • Commit merged branch -
    -
    cvs commit -m "Merged fix for problem xyz from trunk to branch" buggycode.hpp
    -
    -
    • -
  • Go back to main trunk -
    -
    cvs update -A
    -
    -
    • -
  • Move tag to a new merged point -
    -
    cvs tag -F -c merged_to_RC_1_28_2 buggycode.hpp
    -
    -
    • -
  • Repeat as needed -
    • -
-
-
    -
  • WinCVS:
    • -
-
-
    -
  • After fixed code is committed to main branch, switch to the release - candidate branch:
    • -
-
-
-

Select file(s) if not already selected.

-

Modify | Update selection... | - Update settings | Sticky options | Retrieve rev/tag/branch: RC_1_26_2 | OK

-
-
-
    -
  • Merge changes from main trunk into the release candidate branch:
    • -
-
-
-

Modify | Update selection... | - Update settings | Merge options | Only this rev/tag: - merged_to_RC_1_26_2 - | Plus with this rev/tag: HEAD | OK

-
-
-
    -
  • Commit merge results:
    • -
-
-
-

Modify | Commit... | Enter log message: ... | OK

-
-
-
    -
  • Go back to main trunk:
    • -
-
-
-

Modify | Update selection... | Update settings | Reset any sticky - date/tag/-k options | OK

-
-
-
    -
  • Tag as new merge point:
    • -
-
-
-

Modify | Create tag on selection... | Create tag settings | Enter the tag - name to create: merged_to_RC_1_26_2, Overwrite existing tags - with same name | OK.

-
-
-
-
-

Release Procedures for the Release Manager

-

At time of branch-for-release:

-
    -
  • Tag the main trunk  merged_to_RC_n_n_n.
    • -
  • Branch the main trunk with the tag RC_n_n_n.
    • -
-

See Release Manager's Checklist for -full details.

-

FAQ

-

What is the purpose of the -merged_to_RC_n_n_n tag? This tag allows multiple merges from the -main trunk to the release candidate branch. Without it, merging an initial main -trunk fix  into the release candidate branch would work, but merging a -second fix from main trunk to release candidate branch would result in a merge -conflict. Although this procedure seems convoluted, it works much better in -practice than several prior procedures we tried.

-

Acknowledgements

-

This web page was written by Beman Dawes, with helpful suggestions from Dave -Abrahams and Steve Robbins. Jim Hyslop contributed the original CVS procedures. -Updated by Jeff Garland after 1.29 release based on list discussions.

-
-

Revised: -02 October, 2003

- -

© Copyright Beman Dawes 2002

- -

Distributed under the Boost Software License, Version 1.0. (See -accompanying file LICENSE_1_0.txt or copy -at http://www.boost.org/LICENSE_1_0.txt)

- - - - \ No newline at end of file