| Table of Contents |
|---|
Source Control Organization
...
Releases within a major version and the latest minor version are in a branch called maint-x where x is the major release. For example the 2.x SP code is in the maint-2 branch.
Releases within a previous minor version (patch releases) are in a branch called maint-x.y where x is the major release and y is the minor release. For example, the 1.4.x xmltooling code is in the maint-1.4 branch.
...
The basic summary follows, and then each step is elaborated.
Generate source distributions for use by the later steps.
Test Mac, and macport builds.
Do the Windows build and installers.
Generate prerelease "final" RPM packages.
Upload final source distributions and Windows installers to public site.
Generate official RPM packages.
Update the macports.
Source Prep
The first step is to prepare candidate source releases. The Mac is recommended for this purpose as discussed earlier, because it seems to produce the best autoconf results for the most platforms.
Ensure all the dependencies are available.
Pull the candidate sources from Git.
In sequence, bootstrap each project with
autoreconf, then run the configure, make, make install sequence.After fixing any build issues, prepare each of the distributions with make dist.
macOS Smoke Test
Other than the now unsupported Solaris, the next most likely source of regressions will be macOS, so a build there is the next step. After a build from the console, it's a good idea to actually do a macport test because they use the more strict clang compiler now. Local port testing is fairly obnoxious but a straightforward way is as follows:
Place the source distributions on an accessible web site.
Move to /opt/local/var/macports/sources/rsync.macports.org/release/ports
Modify the installed Portfiles beneath these folders. Make sure to update versions and the checksums.
Run
portindexagainst the modified tree.Test port upgrade or installs of the candidate portfiles.
Windows Build
The Windows build tends to be in better shape if its the primary development platform, but for other developers this may not be the case. It may be advantageous to move the Windows build earlier to catch regressions there, because any fixes end up risking regressions to the rest of the builds, so the goal once this step is reached is for the chance of regressions to be low.
...
For the builds to be successful, special project configuration settings are required. These are set from the command line or in the "Advanced|Project Config" option tab:
| Code Block | |
|---|---|
| title | osc meta prjconf -e |
The purpose of these settings is to append a distribution-specific tag (e.g. "el5") to the package names in the Red Hat platforms, and to turn off a package substitution rule on Red Hat and CentOS that prevents us from using our updated xerces-c-3.1.1 package instead of the one that comes with Red Hat. It also fixes dependency issues with Apache on 8.
Other special build notes:
Red Hat and CentOS platforms need to have the "Debuginfo Flag" setting turned off under "Repositories". If not, the builds will fail. I don't know why.
Apart from all that, the builds should be incident-free by the time a release is being done, but there are usually glitches and issues to work out prior to the release being close to done. The specfiles do not come from the actual source distribution, so what usually happens is that once the sources are frozen, a change or two might be made to the specfiles within the build service to get the packages done. Those get checked back in eventually, but may not make it into the actual release being done at the time unless the sources need to be regenerated for some other reason anyway. (As noted earlier, usually this can't be done while the production packages are being generated.)
...
The initial set of release artifacts (and the appropriate release location) consists of:
shibwww@shibboleth.net/home/shibwww/html/downloads/c++-opensaml/ver/xmltooling-ver.tar.gz
shibwww@shibboleth.net/home/shibwww/html/downloads/c++-opensaml/ver/opensaml-ver.tar.gz
shibwww@shibboleth.net/home/shibwww/html/downloads/service-provider/ver/shibboleth-sp-ver.tar.gz
shibwww@shibboleth.net/home/shibwww/html/downloads/service-provider/ver/win32/shibboleth-sp-ver-win32.msi
shibwww@shibboleth.net/home/shibwww/html/downloads/service-provider/ver/win64/shibboleth-sp-ver-win64.msi
shibwww@shibboleth.net/home/shibwww/html/downloads/service-provider/extensions/shibresolver/ver/shibboleth-resolver-ver.tar.gz
ver is replaced by the version number. A symlink called latest is also reset in the two product directories to point to the updated version directory.
...