source: branches/gsoc11-statistics/base/portmgr/ReleaseProcess @ 105085

Last change on this file since 105085 was 105085, checked in by snc@…, 8 years ago

merge from trunk

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id
File size: 12.6 KB
Line 
1
2= MacPorts Release Process =
3
4This file documents the evolving MacPorts release process.
5$Id: ReleaseProcess 105085 2013-04-09 18:46:31Z snc@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.9.x, 2.0.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_2_0) 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" https://svn.macports.org/repository/macports/branches/release_2_0
43 svn cp [-r<rev>] -m "commit-message" https://svn.macports.org/repository/macports/trunk/base \
44     https://svn.macports.org/repository/macports/branches/release_2_0
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 latest version of the subversion port so that merge
53tracking information can be maintained between release branches and trunk/base if you intend
54to merge revisions back and forth between them, which is a very likely scenario.
55
56
57=== Prepare the code for Release ===
58
59In preparation for a release, several things should be completed within the code:
60
61 * Update the file base/ChangeLog in both trunk and the release branch to reflect the appropriate changes.
62 * Update the file base/config/macports_version with the target release number. The content of this file
63   is recorded as the MacPorts version at MacPorts build time, as displayed by the port command, and it's
64   also used by the selfupdate procedure to determine whether a newer version of code is available.
65   It should be different between trunk and the release branch, the former greater to differentiate it from
66   the latter.
67 * Preserve the file base/config/mp_version at the 1.800 fixed value if selfupdate backwards compatibility
68   with pre 1.8.0 MacPorts installations is still desired (cf. svn's r43571).
69 * Update the autoconf 'configure' script through the provided base/regen.sh script once the version number
70   in mp_version has been changed, since the former reads the latter.
71 * Make sure that these and any other changes or bug fixes are made on and/or merged between the release branch
72   and trunk as needed. For instance, if you've made changes to ChangeLog only on the release branch,
73   those changes should be merged back into trunk as well.
74
75
76=== Tag the Release ===
77
78Once the release is ready, it must be tagged so that the release components may be fetched in the future,
79to ensure replicability. Generally, a release candidate is first tagged and built. When and if it is
80approved as the actual release, an additional tag is created that names the same sources.
81
82Tagging conventions:
83
84 * release_2_0_0-beta2 (beta 2 for release 2.0.0)
85 * release_2_0_0-rc1 (release candidate 1 for release 2.0.0)
86 * release_2_0_0 (tagged release 2.0.0)
87 * release_2_0_0-archive (tagged release 2.0.0 -- complete archive)
88 * release_2_0_1 (2.0.1 release)
89
90We first tag the branched base directory to make up the final release:
91
92 svn cp -m "commit-message" https://svn.macports.org/repository/macports/branches/release_2_0 \
93     https://svn.macports.org/repository/macports/tags/release_2_0_0
94
95Although only the base subdirectory is branched and tagged for a given major release, we also create a
96separate tag for the entire tree (base sources and full ports tree) at the time the final release tag is
97created (only for major releases, x.y.0), in order to provide a stake in the ground that specifies a set
98of ports intended to work with that release. Note that this tag incorporates the entire svn trunk directory
99at the revision number at which the final release was tagged.
100
101The necessary working copy to create such a tag is created by checking out all of trunk at the specific
102revision of the final tagging of base and then switching the base directory to the appropriate release
103tag URL. For instance:
104
105 svn co [-r<rev>] https://svn.macports.org/repository/macports/trunk release_2.0.0-archive
106 cd release_2.0.0-archive/base
107 svn switch https://svn.macports.org/repository/macports/tags/release_2_0_0/base
108
109And finally we tag the entire directory as release_2_0_0-archive:
110
111 cd ../../
112 svn cp -m "commit-message" release_2.0.0-archive https://svn.macports.org/repository/macports/tags/release_2_0_0-archive
113
114
115=== Create & Post Release Tarballs ===
116
117The release tarballs are tar.bz2 and tar.gz archives of the base directory only and of the entire svn tree
118for a particular release. They are named with the following naming convention:
119
120 MacPorts-2.0.0.tar.{bz2,gz} (base directory only, corresponding to tag release_2_0_0)
121 MacPorts-2.0.0-archive.tar.{bz2,gz} (complete archives corresponding to tag release_2_0_0-archive)
122
123The following commands issued to the top level Makefile will generate all the tarballs and checksums:
124
125 make ARC=yes DISTVER=2.0.0 distfromsvn
126
127Note that if you omit the "ARC=yes" flag at the start of the make call then the full archive tarballs will not be produced.
128
129All these tarballs are uploaded to the http://distfiles.macports.org/MacPorts/ directory. At present, this must
130be done with the help of the MacOSForge sysadmin.
131
132Additionally, a file is created, and posted to the same location, that contains md5, sha1, rmd160, and sha256 checksums
133for each of the files:
134
135 MacPorts-2.0.0.chk.txt
136 (We should have a way to sign these checksums, and have the signer's keys posted somewhere.
137 Security experts in the project, would you be interested in leading this effort? Eric? Mark? Anyone else?)
138
139
140=== Create Release Packages and Disk Image(s) ===
141
142The dmg is a Mac OS X disk image that contains a standalone installer, configured in the usual way, for major
143MacPorts releases (x.y.0), named in a consistent fashion and incorporating the OS version for which it
144was built.
145
146For 10.6 and newer, we now build flat packages, so an enclosing dmg is not necessary.
147
148 MacPorts-2.0.0-10.5-Leopard.dmg
149 MacPorts-2.0.0-10.6-SnowLeopard.pkg
150 MacPorts-2.0.0-10.7-Lion.pkg
151
152To create a pkg or dmg, 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 pkg
155for the release). Make sure the ports tree you're using to build the pkgs is fully up to date.
156
157 sudo port -d pkg MacPorts
158 sudo port -d dmg MacPorts
159
160Name each pkg/dmg appropriately, and then sign the pkgs with a Developer ID (make sure to use the
161Installer certificate, not the Application one):
162
163 cd work
164 mv MacPorts-2.0.0.pkg unsigned/MacPorts-2.0.0-10.7-Lion.pkg
165 productsign --sign "Developer ID Installer: John Doe" unsigned/MacPorts-2.0.0-10.7-Lion.pkg MacPorts-2.0.0-10.7-Lion.pkg
166
167After signing, generate checksums, which will need to be added to the existing checksums
168file in the downloads directory:
169
170 for pkg in MacPorts-2.0.0-*.{pkg,dmg}; do for type in -md5 -sha1 -ripemd160 -sha256; do openssl dgst $type $pkg; done >> MacPorts-2.0.0.chk.txt; done
171
172These new products, along with the new checksums, also have to be posted to the appropriate
173directory of the MacPorts distfiles server. Developers are required to validate the generated installer as
174thoroughly as possible through extensive testing, which is mainly why this step of the release process
175is not automated through a Makefile target or similar. A good way of validating the installer is to first
176create the destroot of the port and examine it for:
177
178 * Linking: libraries and binaries should not be linked against anything that's not present by default
179   on a vanilla Mac OS X installation + developer tools, excluding even the MacPorts installation prefix;
180   this can be accomplished through the use of otool's -L flag. Currently the libraries and binaries in need
181   of linking validation are:
182             ${destroot}/opt/local/bin/daemondo
183             ${destroot}/opt/local/share/macports/Tcl/darwintrace1.0/darwintrace.dylib
184             ${destroot}/opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib
185             ${destroot}/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib
186             ${destroot}/opt/local/share/macports/Tcl/registry2.0/registry.dylib
187 * Universal building: All the files that need linking confirmation in the step above also need to be
188   confirmed to be universal (i386/ppc on 10.5 and earlier, i386/x86_64 on 10.6 and later). A way to do this
189   is with the file(1) command:
190             file ${destroot}/opt/local/bin/daemondo:
191                  ${destroot}/opt/local/bin/daemondo: Mach-O universal binary with 2 architectures
192                  ${destroot}/opt/local/bin/daemondo (for architecture ppc):  Mach-O executable ppc
193                  ${destroot}/opt/local/bin/daemondo (for architecture i386): Mach-O executable i386
194 * tclsh shell invoked by our scripts: all scripts installed in ${destroot}/opt/local/bin (that is port,
195   portindex and portmirror) should invoke the tclsh shell through a call like:
196             #!/bin/sh
197             #\
198             exec /usr/bin/tclsh "$0" "$@"
199   thus ensuring that the default Mac OS X bundled Tcl is used in our scripts.
200 * macports1.0 Tcl package: The macports1.0 Tcl package should be sourced off its location in /opt/local/share/macports/Tcl/macports1.0
201   in every single one of our scripts in ${destroot}/opt/local/bin.
202 * Miscellaneous: anything else that might seem out of the ordinary for a fully default-configured MacPorts
203   installation.
204
205Once the above requirements have been positively asserted, the one remaining test is to make sure that the
206dmg mounts in the Finder when double-clicked, and that the pkg contained therein properly starts up Installer.app
207when it's double-clicked.
208
209
210=== Make the Release Available through Self-Update ===
211
212In order to make the release version available through selfupdate, the base/config/RELEASE_URL file in svn
213trunk needs to be updated with the tag of the release to distribute. This file is read by the cron job that
214makes the code available via rsync. See base/portmgr/mprsyncup. Though not strictly necessary, it's also good
215practice to update the same file accordingly in its branched guise.
216
217
218=== Update trunk's version for next release ===
219
220Once trunk is to be used for development of the next major version, increase its version information to
221indicate it's moved past the release version by setting the patch-level version to 99, e.g. 2.0.99 (in
222trunk/base/config/macports_version).
223
224
225=== Notify the Public of the Release ===
226
227Once the release has been posted, notification of the release should be sent/posted to the following places:
228
229 * The macports-announce@, macports-users@ and macports-dev@ mailing lists.
230 * The MacPorts website, by adapting the $macports_version_major and $macports_version_latest variables as
231   appropriate in the trunk/www/includes/common.inc file.
232 * [https://trac.macports.org/news/] The MacOSforge news section (submitter: portmgr@)
233 * [http://freecode.com/projects/macports/ Freecode] (submitter: mww@)
234 * [http://www.versiontracker.com/dyn/moreinfo/macosx/26679 VersionTracker] (submitter: mij@)
235 * [http://sourceforge.net/projects/macports/ sourceforge] (submitted: rhwood@)
236 * [http://www.macupdate.com/info.php/id/21309/macports MacUpdate] (submitter: ???)
237 * [http://twitter.com/macports twitter] (submitter: raimue@)
238 * (Where else?)
239
240
241=== Use of new features in Portfiles ===
242
243Using new features introduced by a release should be delayed for 14 days. This
244should allow users to upgrade their installations to the new release. This
245delay matches the warning about outdated ports tree sources.
246
247
Note: See TracBrowser for help on using the repository browser.