releases.txt

来自「linux subdivision ying gai ke yi le ba」· 文本 代码 · 共 241 行

                Subversion Tarball Release Procedure
                ====================================

1. When starting a new major or minor line create a release branch
   from the "golden" revision number (otherwise skip to step 3):

   svn cp -rHEAD -m"Create release X.Y.Z branch" \
      http://svn.collab.net/repos/svn/trunk \
      http://svn.collab.net/repos/svn/branches/X.Y.x

   All release of the X.Y line will come out of this branch.
   Changes from trunk will be merged based upon compatability
   rules and voting as explained in HACKING.

2. Bump the version numbers in svn_version.h on trunk.

    Note that this should be the next major/minor line we plan on doing.
    E.G. if you're making the 1.1.x branch then the svn_version.h in trunk
    should reflect 1.2.0.

    You'll commit this change along with the change in step 3. 

3. Tweak trunk to have a new CHANGES section.

   a) Begin a new section at the top of the CHANGES file with:

      Version X.Y.Z (released XX Month 200X, from branches/X.Y.Z)
      http://svn.collab.net/repos/svn/tags/X.Y.Z

   b) Commit.

4. Create a working copy (wc) from the release branch:

   $ svn co http://svn.collab.net/repos/svn/branches/X.Y.Z

5. Merge fixes and changes from trunk. 

   Only very important bugfixes are allowed to merge from the trunk to
   the release branch. A decision of a merge happends in the STATUS 
   file as documented in HACKING. 

   In the following example, we pretends to merge revision 7868 into
   the release branch:

   a) cd to your branch release working copy and run:

     $ svn merge -r7867:7868 http://svn.collab.net/repos/svn/trunk

   b) Commit the changes:

      $ svn ci -m "Merge r7868 into the 0.34.0 branch"

   c) cd to your wc for http://svn.collab.net/repos/svn/trunk and add
      a note under User-visible changes or Developer-visible changes. 

         * fixed: Java bindings compilation.

      Note: CHANGES is maintained on the trunk because future releases should
      have past releases CHANGES entries.  It will be merged onto the branch
      just before a release.

   d) Commit

6. It's release time, so cd to the release branch's working copy.

   Make sure your release branch wc has the following packages
   extracted into the root of the wc tree:

   apr           (see INSTALL, section I)
   apr-util      (see INSTALL, section I)
   neon          (see INSTALL, section I)

   To install apr/apr-util, see INSTALL, section I.1.

   To install neon, see INSTALL, section I.5.

   To configure/install Apache (httpd-2.X.YY), see INSTALL,
   section I.7 and section III.  If you maintain a separate
   build/release area, and don't want to over-write an
   existing/working installation of Apache, you may want to use
   --prefix=/usr/local/apache2 to install a parallel instance of
   Apache.

   To make sure httpd.conf is properly set up for DAV access, see
   subversion/tests/clients/cmdline/README.

   Also, see sections 'Building the Latest Source under Unix' and
   'BUILDING A SUBVERSION SERVER' in the INSTALL file. for more
   detailed build information.

7. Merge CHANGES into the release branch. Do it the same way as described in
   section 4 in this document when merging fixes to the release branch.

8. Run './dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z'

   Watch dist.sh's output to make sure everything goes smoothly; when
   it's done, you'll have 'subversion-X.Y.Z.tar.gz' and 
   'subversion-X.Y.Z.tar.bz2' in the cwd.

9. Test one or both of the tarballs:
     a) tar zxvf subversion-X.Y.Z.tar.gz;  cd subversion-X.Y.Z
     b) ./configure

         See INSTALL, section III.B for detailed instructions
         on configuring/building Subversion.

         If you installed Apache in some place other than the default, as
         mentioned above, you will need to use the same
         --prefix=/usr/local/apache2 option as used to configure Apache.

         You may also want to use --enable-mod-activation, which will
         automatically enable the required Subversion modules in the
         Apache config file.

     c) make
     d) make check
     e) make install (this activates mod_dav)
     f) make davcheck

        For this, start up Apache after having configured according to
        the directions in subversion/tests/clients/cmdline/README.

        Make sure, that if you maintain a development installation of
        apache, that you check the config file and update it for the
        new release area where you're testing the tar-ball.

        (Unless you rename the tree which gets extracted from the
        tarball to match what's in httpd.conf, you will need to edit
        httpd.conf)

     g) make svncheck

        First, start up svnserve with these args:

         $ subversion/svnserve/svnserve -d -r \
           `pwd`/subversion/tests/clients/cmdline

        -d tells svnserve to run as a daemon
        -r tells svnserve to use the following directory as the
           logical file system root directory.

        After svnserve is running as a daemon 'make svncheck' should run

     h) Then test that you can check out the subversion repository
        with this environment:

         subversion/clients/cmdline/svn co \
                        http://svn.collab.net/repos/svn/trunk

10. Use GPG to sign release. 

   [Details to be filled in later].

11. Upload the tarballs to http://subversion.tigris.org/tarballs/.

    Currently, the ability to upload a tarball requires login access
    to subversion.tigris.org.  One of the collab.net developers can do
    this.  We'd like to make possible for the Release Manager to do by
    themselves, of course, but as tigris.org has its own security
    policies, this will require some negotiation.  For now, just grab
    a collab.net person on IRC, or plan for them to be available.
    Sorry for the inconvenience.

12. Link to the tarballs from the Downloads page:

      http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260

    Here's how:

     a. Log into http://subversion.tigris.org/
     b. Click on the 'Downloads link (left frame at the top)
     c. Click on the 'Source tarballs' link (main frame)
     d. Click on the 'Add a file' link (top, main frame, under 'File Sharing')
     e. Fill in the following fields:

       Name: subversion-X.Y.Z.tar.gz (replace X.Y.Z with the release number)
       Status: Stable
       Description: Subversion release X.Y.Z (MD5: <md5sum of tarball>)
       Contents: (choose 'Link', then enter
           http://subversion.tigris.org/tarballs/subversion-X.Y.Z.tar.gz)

    f. Click Submit

12. Copy the branch into the tags directory in the repository.

      svn cp -m "Make tag for release X.Y.Z."     \
          http://svn.collab.net/repos/svn/branches/X.Y.x   \
          http://svn.collab.net/repos/svn/tags/X.Y.Z

13. Switch your working copy to the tag.

      svn switch http://svn.collab.net/respos/svn/tags/X.Y.Z

14. Copy svn_version.h.dist (that dist.sh made in the top level of your wc)
    to subversion/includes/svn_version.h and commit.

      cp svn_version.h.dist subversion/include/svn_version.h
      svn commit -m "Update svn_version.h to match tarball." \
          subversion/include/svn_version.h

    Now that the release is public and the tag matches the tarball, changes
    are not allowed on the tag.  If we discover problems with the release,
    then we will fix them on the branch we did the release off of and do a
    new release.

15. Bump the svn_version.h for the original branch.

    a) Switch your working copy back to the branch.

         svn switch http://svn.collab.net/repos/svn/branches/X.Y.x

    b) Modify subversion/include/svn_version.h
       If you just did 1.0.2 then svn_version.h should have the proper
       values for 1.0.3 and so on. 

16. Update the website.

   a) Edit the www/project_status.html file appropriately in /trunk *NOT*
      in the release branch and commit. Remember edit a search term at the
      end of release's issue link. 

      If you used 'svn switch' in 3b above, you can simply 'switch' back
      to /trunk using:

         svn switch http://svn.collab.net/repos/svn/trunk

      then edit the www/project_status.html file appropriately.

   b) Commit the modifications of www/project_status.html

   c) Remind someone with an @collab.net address to update the live
      web site (we used to have a servlet for this, but at the moment
      we don't).

17. Post news item <http://subversion.tigris.org/servlets/ProjectNewsAdd>,
    and send an announcement to dev@, users@, and announce@ lists.
    Remember to include the URL and MD5 checksum in the announcement.

18. Someone with administrative access should upgrade svn.collab.net
    to head.  (This is not usually the release manager.)