source: trunk/base/ReleaseProcess @ 23263

Last change on this file since 23263 was 22648, checked in by jmpp@…, 13 years ago

We don't always want the "distfromsvn" target of the main Makefile to build the full archive tarballs
(the ones including the dports tree), for instance when testing rc's we may only want base tarballs, so
lets add a conditional there.

I'm also updating the ReleaseProcess file to reflect this change and to use the recommended URL -> URL syntax
for the copy command when branching and tagging.

File size: 9.0 KB
2== MacPorts Release Process ==
4This page documents the evolving MacPorts release process.
7== Goals of a Release ==
9There are several goals in the release process:
11* Make a specific version of MacPorts available to users.
12* Archive the materials (code, documentation, etc) that compose the release.
13* Replicatability: Enable the release to be regenerated.
14* Consistency: codify naming, network locations, etc, for released components.
15* Ensure that the user base and public is notified of the release.
18== Steps to a Release ==
20The following steps to a release are documented in more detail below:
22* Create an svn branch to carry the release.
23* Prepare the code for release.
24* Tag the release.
25* Create release products: tarball and dmg.
26* Post release products.
27* Make release version available through selfupdate.
28* Notify public of the release.
31=== Create a Release Branch ===
33For 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:
35* Choose the svn revision from which to create the branch, most likely based off trunk.
36* Create the branch (e.g. release_1_4) through the svn "copy" command for history preservation:
38 svn cp -r<rev>
40The 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.
42Only the base subdirectory, not the dports subdirectory, is branched for a given release.
45=== Prepare the code for Release ===
47In preparation for a release, several things should be completed within the code:
49* Update the file base/ChangeLog to reflect changes in the release.
50* Update the file base/config/dp_version with the target release number. Note that this is a floating point number that corresponds to the release number; it should correspond roughly to the release number where possible. Release 1.4.1, for instance, would be represented by the floating point number 1.41. The version number in dp_version is displayed by the port command as the version of MacPorts, and is used by the selfupdate command to determine whether a newer version of code is available.
51* Make sure that these, and any other changes or bug fixes as necessary, are made on and/or merged into the release branch. If you've made changes to ChangeLog only on the release branch, those changes should be merged to trunk as well.
54=== Tag the Release ===
56Once the release is ready, it must be tagged so that the release components may be fetched in the future, to ensure replicatability.
58Generally, a release candidate is first tagged and built. When and if it is approved as the actual release, an additional tag is created that names the same sources.
60Tagging conventions:
62* release_1_4_0-rc1 (release candidate 1 for release 1.4)
63* release_1_4_0 (tagged release 1.4)
64* release_1_4_0-archive (tagged release 1.4 -- complete archive)
65* release_1_4_1 (1.4.1 release)
67We first tag the branched base directory for the release
69 svn cp
71Although 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.
73Such 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:
75 svn co macports/release-1.4
76 cd macports/release-1.4/base
77 svn switch
79And finally we tag the entire directory as release_1_4_0-archive
81 svn cp macports/release-1.4
82(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
85=== Create & Post Release Tarballs ===
87The 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:
89 MacPorts-1.4.tar.{bz2,gz} (base directory only, corresponding to tag release_1_4_0)
90 MacPorts-1.4-archive.tar.{bz2,gz} (complete archives corresponding to tag release_1_4_0-archive)
92The following commands issued to the top level Makefile will generate the archives and checksums:
94 make DISTVER=1.4 DISTTAG=release_1_4_0 distfromsvn
96Note 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.
98These tarballs are uploaded via svn to directory.
100Additionally, a file is created, and posted to the same location, that contains md5, sha1, and rmd160 checksums for each of the files:
102 MacPorts-1.4.chk.txt
103(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?)
106=== Create Release Disk Image(s) ===
108The 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.
110 MacPorts-1.4-10.3.dmg
111 MacPorts-1.4-10.4.dmg
113To 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.
115 port dmg macports
117Name the dmg appropriately, and generate checksums, which will need to be added to the checksum file:
119 cd work
120 mv MacPorts-1.4.dmg MacPorts-1.4-10.4.dmg
121 for type in -md5 -sha1 -ripemd160; do openssl dgst $type MacPorts-1.4-10.4.dmg; done
123These 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.
126=== Make the Release Available through Self-Update ===
128In order to make the release version available through selfupdate, the base/config/RELEASE_URL file in svn trunk needs to be updated with the tag of the release to distribute. This file is read by the cron job that makes the code available via rsync. See base/portmgr/mprsyncup.
131=== Notify the Public of the Release ===
133Once the release has been posted, notification of the release should be sent/posted to the following places:
135* The and mailing lists.
136* Apple's [ Mac OS X software download page] (submitter: mww@)
137* [ Freshmeat] (submitter: mww@)
138* [ VersionTracker] (submitter: mij@)
139* (Where else? -- MacUpdate?)
140(Following three locations --last two being leftovers from darwinports days-- need to be carefully thought out and reworked in view of a much --*URGENTLY*-- needed website redesign!!!)
141* Wordpress news section at the main MacPorts site,
142* The [ getdp] and [ main] sites (the "$dp_version" variable in the includes/ file for the main English site --www/includes/ and each localization has to be updated with the release version)
143* The darwinports wiki (updating the "Current DarwinPorts release" line on the [[DarwinPorts|main]] page)
146== Additional Release Resources ==
148* Landon Fuller's [ release process] suggestions
Note: See TracBrowser for help on using the repository browser.