[23585] branches/release_1_4/base/ReleaseProcess

source_changes at macosforge.org source_changes at macosforge.org
Wed Apr 4 15:34:44 PDT 2007


Revision: 23585
          http://trac.macosforge.org/projects/macports/changeset/23585
Author:   jmpp at macports.org
Date:     2007-04-04 15:34:44 -0700 (Wed, 04 Apr 2007)

Log Message:
-----------

Not dropping the trailing .0 helps things (distver, disttag, branch, tag, downloads dir, portfile) work out of the box,
so I'm standarizing that.

Modified Paths:
--------------
    branches/release_1_4/base/ReleaseProcess

Modified: branches/release_1_4/base/ReleaseProcess
===================================================================
--- branches/release_1_4/base/ReleaseProcess	2007-04-04 22:30:23 UTC (rev 23584)
+++ branches/release_1_4/base/ReleaseProcess	2007-04-04 22:34:44 UTC (rev 23585)
@@ -30,12 +30,12 @@
 
 === Create a Release Branch ===
 
-For each major release (i.e. 1.3, 1.4, etc.) an appropriate branch is created with a consistent name. To do this, two things are required:
+For each major release (i.e. 1.3.0, 1.4.0, etc.) an appropriate branch is created with a consistent name. To do this, two things are required:
 
 * Choose the svn revision from which to create the branch, most likely based off trunk.
-* Create the branch (e.g. release_1_4) through the svn "copy" command for history preservation:
+* Create the branch (e.g. release_1_4_0) through the svn "copy" command for history preservation:
 
- svn cp -r<rev> http://svn.macports.org/repository/macports/trunk/base/ http://svn.macports.org/repository/macports/branches/release_1_4
+ svn cp -r<rev> http://svn.macports.org/repository/macports/trunk/base/ http://svn.macports.org/repository/macports/branches/release_1_4_0
 
 The actual release, alpha or beta releases, release candidates, and any point releases will all live on this branch, and tagged appropriately and if necessary (a must for the actual releases, optional for beta snapshots) into the /tags svn directory.
 
@@ -59,26 +59,26 @@
 
 Tagging conventions:
 
-* release_1_4_0-rc1 (release candidate 1 for release 1.4)
-* release_1_4_0 (tagged release 1.4)
-* release_1_4_0-archive (tagged release 1.4 -- complete archive)
+* release_1_4_0-rc1 (release candidate 1 for release 1.4.0)
+* release_1_4_0 (tagged release 1.4.0)
+* release_1_4_0-archive (tagged release 1.4.0 -- complete archive)
 * release_1_4_1 (1.4.1 release)
 
 We first tag the branched base directory for the release
 
- svn cp http://svn.macports.org/repository/macports/branches/release_1_4 http://svn.macports.org/repository/macports/tags/release_1_4_0
+ svn cp http://svn.macports.org/repository/macports/branches/release_1_4_0 http://svn.macports.org/repository/macports/tags/release_1_4_0
 
 Although only the base subdirectory is branched and tagged for a given major release, we also create a seperate tag for the entire tree (base sources and full ports tree) at the time a release tag is created, in order to provide a stake in the ground that specifies a set of ports intended to work with that release. Note that this tag incorporates the entire svn trunk directory at TOT (top of tree), except for the base directory which is kept at the point of the release.
 
 Such a composite directory may be created by checking out all of trunk and then switching the base directory to the appropriate release tag URL. For instance:
 
- svn co http://svn.macports.org/repository/macports/trunk macports/release-1.4
- cd macports/release-1.4/base
+ svn co http://svn.macports.org/repository/macports/trunk macports/release-1.4.0
+ cd macports/release-1.4.0/base
  svn switch http://svn.macports.org/repository/macports/tags/release_1_4_0
 
 And finally we tag the entire directory as release_1_4_0-archive
 
- svn cp macports/release-1.4 http://svn.macports.org/repository/tags/release_1_4_0-archive
+ svn cp macports/release-1.4.0 http://svn.macports.org/repository/tags/release_1_4_0-archive
 (NOTE: copying a "mixed" directory like this to a different URL is highly counter-recommended by developers in #svn @freenode, as it may lead to great history confusion, so an alternate procedure that gets us in a "legal" svn way what James first outlined with a cvs framework in mind should be sought. Nevertheless, I can't seem to find it at the moment, so I'd love it if more experienced svn users could take a stab at it! Daniel...? Blair...? Anyone else? For the record, James' orginal document is at http://trac.macports.org/projects/macports/browser/users/jberry/mediawiki_archive/releaseprocess.txt)
 
 
@@ -86,20 +86,20 @@
 
 The release tarballs are tar.bz2 and tar.gz archives of the  base directory only and of the entire svn tree for a particular release. They are named with the following naming convention:
 
- MacPorts-1.4.tar.{bz2,gz} (base directory only, corresponding to tag release_1_4_0)
- MacPorts-1.4-archive.tar.{bz2,gz} (complete archives corresponding to tag release_1_4_0-archive)
+ MacPorts-1.4.0.tar.{bz2,gz} (base directory only, corresponding to tag release_1_4_0)
+ MacPorts-1.4.0-archive.tar.{bz2,gz} (complete archives corresponding to tag release_1_4_0-archive)
 
 The following commands issued to the top level Makefile will generate the archives and checksums:
 
- make DISTVER=1.4 DISTTAG=release_1_4_0 distfromsvn
+ make DISTVER=1.4.0 distfromsvn
 
 Note that DISTTAG is generated from DISTVER automatically. But our naming convention drops the last .0 in the DISTNAME, so for x.y.0 releases, you want to specify these distinctly, as above. Also, you need to pass the "ARC=yes" flag on the command line to the "distfromsvn" target if you wish to produce tarballs for the full archive.
 
-These tarballs are uploaded via svn to http://svn.macports.org/repository/macports/downloads/MacPorts-1.4/ directory.
+These tarballs are uploaded via svn to http://svn.macports.org/repository/macports/downloads/MacPorts-1.4.0/ directory.
 
 Additionally, a file is created, and posted to the same location, that contains md5, sha1, and rmd160 checksums for each of the files:
 
- MacPorts-1.4.chk.txt
+ MacPorts-1.4.0.chk.txt
 (We should have a way to sign these checksums, and have the signer's keys posted somewhere. Security experts in the project, would you be interested in leading this effort? Eric? Mark? Anyone else?)
 
 
@@ -107,8 +107,8 @@
 
 The dmg is a Mac OS X disk image that contains a standalone installer for the release, named in a consistent fashion and incorporating the OS version for which it was built.
 
- MacPorts-1.4-10.3.dmg
- MacPorts-1.4-10.4.dmg
+ MacPorts-1.4.0-10.3.dmg
+ MacPorts-1.4.0-10.4.dmg
 
 To create the disk image, use the macports port; the Portfile will need to be updated to incorporate the proper release version and the release tarballs will need to be already uploaded to the downloads section of the site (wherefrom the sources are fetched by the macports port to build the dmg for the release). Checksums need to be adapted likewise.
 
@@ -117,8 +117,8 @@
 Name the dmg appropriately, and generate checksums, which will need to be added to the checksum file:
 
  cd work
- mv MacPorts-1.4.dmg MacPorts-1.4-10.4.dmg
- for type in -md5 -sha1 -ripemd160; do openssl dgst $type MacPorts-1.4-10.4.dmg; done
+ mv MacPorts-1.4.0.dmg MacPorts-1.4.0-10.4.dmg
+ for type in -md5 -sha1 -ripemd160; do openssl dgst $type MacPorts-1.4.0-10.4.dmg; done
 
 These new products, along with the new checksums file, also have to be posted to the downloads section of the MacPorts svn repository. Developers are required to validate the generated installer as thoroughly as possible through extensive testing, which is mainly why this step of the release process is not automated through a Makefile or similar.
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-changes/attachments/20070404/1170c474/attachment.html


More information about the macports-changes mailing list