source: trunk/base/portmgr/ReleaseProcess @ 43375

Last change on this file since 43375 was 43375, checked in by jmpp@…, 12 years ago

Finally move trunk away from floating point version numbers and instead use the more common x.y.z format, by:

  • Moving base/macports1.0/macports_autoconf.tcl.in to the @MACPORTS_VERSION@ autoconf variable;
  • Introducing a temporary special-case hack to force the selfupdate run in case the $macports::autoconf::macports_version variable is in the old format and smaller or equal to 1.800 (cf. my comment in the selfupdate proc in base/macports1.0/macports.tcl);
  • Removing the now unnecessary base/config/mp_version file, as everything is now determined from the base/config/macports_version file;
  • Removing the @MP_VERSION@ autoconf macro;
  • Regenerating the configure script;

All in all, we should have standard x.y.z version numbers starting from current trunk + 1 (e.g. 1.8.1), since
current trunk will only serve to introduce this code into users' hands first.

PS: I chose to force the upgrade as the special-case hack, since otherwise I'd have to reset the $macports::autoconf::macports_version
variable to achieve the same result, and that seems like it might make some babies out there cry...

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id
File size: 11.8 KB
Line 
1
2= MacPorts Release Process =
3
4This file documents the evolving MacPorts release process.
5$Id: ReleaseProcess 43375 2008-12-10 04:49:53Z jmpp@macports.org $
6
7
8== Goals of a Release ==
9
10There are several goals in the release process:
11
12 * Make a specific version of MacPorts available to users.
13 * Archive the materials (code, documentation, etc) that compose the release.
14 * Replicatability: enable the release to be regenerated.
15 * Consistency: codify naming, network locations, etc, for released components.
16 * Ensure that the user base and public is notified of the release.
17
18
19== Steps to a Release ==
20
21The following steps to a release are documented in more detail below:
22
23 * Create an svn branch to carry the release.
24 * Prepare the code for release.
25 * Tag the release.
26 * Create release products: tarballs and dmgs.
27 * Post release products.
28 * Make release version available through selfupdate.
29 * Notify public of the release.
30
31
32=== Create a Release Branch ===
33
34For each major release (i.e. 1.5.x, 1.6.x, etc.) an appropriate branch is created with a
35consistent name. To do this, two things are required:
36
37 * Choose the svn revision from which to create the branch, most likely based off trunk.
38 * Create the branch (e.g. release_1_6) through the svn "copy" command for history preservation,
39   first creating the needed branch directory to preserve the required directory structure
40   (the 'base' directory level *needs* to exist in each release branch, otherwise selfupdate breaks):
41
42 svn mkdir -m "commit-message" http://svn.macports.org/repository/macports/branches/release_1_6
43 svn cp [-r<rev>] -m "commit-message" http://svn.macports.org/repository/macports/trunk/base \
44     http://svn.macports.org/repository/macports/branches/release_1_6
45
46The actual release, alpha or beta releases, release candidates, and any point releases will all
47live on this branch, and tagged appropriately and if necessary (a must for the actual releases,
48optional for beta snapshots) into the /tags svn directory.
49
50Only the base subdirectory, not the ports subdirectory, is branched for a given release.
51
52It is strongly recommended to use the svnmerge.py tool (provided by the subversion port) to
53maintain merge tracking information between release branches and trunk/base if you intend to
54merge revisions back and forth between them, which is a very likely scenario. To do this, you
55must initialize the tracking information from within the "base" directory of your checkout of
56the branch you intend to manage:
57
58 svn co http://svn.macports.org/repository/macports/branches/release_1_6 branches/release_1_6
59 cd branches/release_1_6/base
60 svnmerge.py init
61 svn ci -F svnmerge-commit-message.txt
62
63
64=== Prepare the code for Release ===
65
66In preparation for a release, several things should be completed within the code:
67
68 * Update the file base/ChangeLog in both trunk and the release branch to reflect the appropriate changes.
69 * Update the file base/config/macports_version with the target release number.  The version number in
70   macports_version is displayed by the port command as the version of MacPorts, and is used by the selfupdate
71   command to determine whether a newer version of code is available. This number should be different
72   between trunk and a release branch, the former greater to differentiate it from the latter.
73 * Update the autoconf 'configure' script through the provided base/regen.sh script once the version number
74   in mp_version has been changed, since the former reads the latter.
75 * Make sure that these and any other changes or bug fixes are made on and/or merged between the release branch
76   and trunk as needed. For instance, if you've made changes to ChangeLog only on the release branch,
77   those changes should be merged back into trunk as well.
78
79
80=== Tag the Release ===
81
82Once the release is ready, it must be tagged so that the release components may be fetched in the future,
83to ensure replicability. Generally, a release candidate is first tagged and built. When and if it is
84approved as the actual release, an additional tag is created that names the same sources.
85
86Tagging conventions:
87
88 * release_1_6_0-rc1 (release candidate 1 for release 1.6.0)
89 * release_1_6_0 (tagged release 1.6.0)
90 * release_1_6_0-archive (tagged release 1.6.0 -- complete archive)
91 * release_1_6_1 (1.6.1 release)
92
93We first tag the branched base directory to make up the final release:
94
95 svn cp -m "commit-message" http://svn.macports.org/repository/macports/branches/release_1_6 \
96     http://svn.macports.org/repository/macports/tags/release_1_6_0
97
98Although only the base subdirectory is branched and tagged for a given major release, we also create a
99separate tag for the entire tree (base sources and full ports tree) at the time the final release tag is
100created (only for major releases, 1.x.0), in order to provide a stake in the ground that specifies a set
101of ports intended to work with that release. Note that this tag incorporates the entire svn trunk directory
102at the revision number at which the final release was tagged.
103
104The necessary working copy to create such a tag is created by checking out all of trunk at the specific
105revision of the final tagging of base and then switching the base directory to the appropriate release
106tag URL. For instance:
107
108 svn co [-r<rev>] http://svn.macports.org/repository/macports/trunk release_1.6.0-archive
109 cd release_1.6.0-archive/base
110 svn switch http://svn.macports.org/repository/macports/tags/release_1_6_0/base
111
112And finally we tag the entire directory as release_1_6_0-archive:
113
114 cd ../../
115 svn cp -m "commit-message" release_1.6.0-archive http://svn.macports.org/repository/macports/tags/release_1_6_0-archive
116
117
118=== Create & Post Release Tarballs ===
119
120The release tarballs are tar.bz2 and tar.gz archives of the base directory only and of the entire svn tree
121for a particular release. They are named with the following naming convention:
122
123 MacPorts-1.6.0.tar.{bz2,gz} (base directory only, corresponding to tag release_1_6_0)
124 MacPorts-1.6.0-archive.tar.{bz2,gz} (complete archives corresponding to tag release_1_6_0-archive)
125
126The following commands issued to the top level Makefile will generate all the tarballs and checksums:
127
128 make ARC=yes DISTVER=1.6.0 distfromsvn
129
130Note that if you omit the "ARC=yes" flag at the start of the make call then the full archive tarballs will not be produced.
131
132All these tarballs are uploaded via svn to the http://svn.macports.org/repository/macports/downloads/MacPorts-1.6.0/
133directory.
134
135Additionally, a file is created, and posted to the same location, that contains md5, sha1, and rmd160 checksums
136for each of the files:
137
138 MacPorts-1.6.0.chk.txt
139 (We should have a way to sign these checksums, and have the signer's keys posted somewhere.
140 Security experts in the project, would you be interested in leading this effort? Eric? Mark? Anyone else?)
141
142
143=== Create Release Disk Image(s) ===
144
145The dmg is a Mac OS X disk image that contains a standalone installer, configured in the usual way, for major
146MacPorts releases (1.x.0), named in a consistent fashion and incorporating the OS version for which it
147was built.
148
149 MacPorts-1.6.0-10.4-Tiger.dmg
150 MacPorts-1.6.0-10.5-Leopard.dmg
151
152To create a disk image, use the MacPorts port. The Portfile will need to be updated to incorporate the
153proper release version and checksums, and the release tarballs will need to be already uploaded to the
154downloads section of the site (wherefrom the sources are fetched by the MacPorts port to build the dmg
155for the release). Make sure the ports tree you're using to build the dmg's is fully up to date, as to
156insure the resource files in the files/ directory of the port are current (fetched through svn:externals
157off the base/portmgr/dmg directory of the current final release tag).
158
159 sudo port -d dmg MacPorts
160
161Name the dmg appropriately, and generate checksums, which will need to be added to the existing checksums
162file in the downloads directory:
163
164 cd work
165 mv MacPorts-1.6.0.dmg MacPorts-1.6.0-10.5-Leopard.dmg
166 for dmg in MacPorts-1.6.0-*.dmg; do for type in -md5 -sha1 -ripemd160; do openssl dgst $type $dmg; done >> MacPorts-1.6.0.chk.txt; done
167
168These new products, along with the new checksums, also have to be posted to the appropriate downloads
169directory of the MacPorts svn repository. Developers are required to validate the generated installer as
170thoroughly as possible through extensive testing, which is mainly why this step of the release process
171is not automated through a Makefile target or similar. A good way of validating the installer is to first
172create the destroot of the port and examine it for:
173
174 * Linking: libraries and binaries should not be linked against anything that's not present by default
175   on a vanilla Mac OS X installation + developer tools, excluding even the MacPorts installation prefix;
176   this can be accomplished through the use of otool's -L flag. Currently the libraries and binaries in need
177   of linking validation are:
178             ${destroot}/Library/Tcl/macports1.0/MacPorts.dylib
179             ${destroot}/opt/local/bin/daemondo (only built on 10.4 and later)
180             ${destroot}/opt/local/share/macports/Tcl/darwintrace1.0/darwintrace.dylib
181             ${destroot}/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
182             ${destroot}/opt/local/share/macports/Tcl/registry2.0/registry.dylib
183             ${destroot}/opt/local/share/macports/Tcl/tclobjc1.0/tclobjc.dylib
184 * Universal building: When building for Tiger and above, all the files that need linking confirmation in the
185   step above also need to be confirmed of the universal type. A way to do this is through the file(1) command:
186             file ${destroot}/opt/local/bin/daemondo:
187                  ${destroot}/opt/local/bin/daemondo: Mach-O universal binary with 2 architectures
188                  ${destroot}/opt/local/bin/daemondo (for architecture ppc):  Mach-O executable ppc
189                  ${destroot}/opt/local/bin/daemondo (for architecture i386): Mach-O executable i386
190 * tclsh shell invoked by our scripts: all scripts installed in ${destroot}/opt/local/bin (that is port,
191   portindex and portmirror) should invoke the tclsh shell through a call like:
192             #!/bin/sh
193             #\
194             exec /usr/bin/tclsh "$0" "$@"
195   thus ensuring that the default Mac OS X bundled Tcl is used in our scripts.
196 * macports1.0 Tcl package: The macports1.0 Tcl package should be sourced off its default location in /Library/Tcl/macports1.0
197   in every single one of our scripts in ${destroot}/opt/local/bin.
198 * Miscellaneous: anything else that might seem out of the ordinary for a fully default-configured MacPorts
199   installation.
200
201Once the above requirements have been positively asserted, the one remaining test is to make sure that the
202dmg mounts in the Finder when double-clicked, and that the pkg contained therein properly starts up Installer.app
203when it's double-clicked.
204
205
206=== Make the Release Available through Self-Update ===
207
208In order to make the release version available through selfupdate, the base/config/RELEASE_URL file in svn
209trunk needs to be updated with the tag of the release to distribute. This file is read by the cron job that
210makes the code available via rsync. See base/portmgr/mprsyncup. Though not strictly necessary, it's also good
211practice to update the same file accordingly in its branched guise.
212
213
214=== Notify the Public of the Release ===
215
216Once the release has been posted, notification of the release should be sent/posted to the following places:
217
218 * The macports-announce@, macports-users@ and macports-dev@ mailing lists.
219 * The MacPorts website, by adapting the $macports_version_major and $macports_version_latest variables as appropriate in the trunk/www/includes/common.inc file.
220 * [http://www.apple.com/downloads/macosx/unix_open_source/macports.html Apple's downloads page] (submitter: jmpp@)
221 * [http://freshmeat.net/projects/macports/ Freshmeat] (submitter: mww@)
222 * [http://www.versiontracker.com/dyn/moreinfo/macosx/26679 VersionTracker] (submitter: mij@)
223 * [http://sourceforge.net/projects/macports/ sourceforge] (submitted: rhwood@)
224 * [http://www.macupdate.com/info.php/id/21309/macports MacUpdate] (submitter: ???)
225 * (Where else?)
Note: See TracBrowser for help on using the repository browser.