How to Prepare a New Release Series¶
Throughout this document, we will refer to the new release series as 3.X
, and the previous release series as 3.OLD
.
For example, if we are creating OSG 3.6, then 3.X
refers to 3.6
, and 3.OLD
refers to 3.5
.
Do first, anytime before the month of the release¶
-
Add 3.X koji tags and targets
-
Modify this script as appropriate and run: https://github.com/opensciencegrid/osg-next-tools/blob/master/koji/create-new-koji-osg3X-tags-etc
In particular, update
SERIES
as appropriate, and include any applicable enterprise linux versions to theEL
loop (eg,el7 el8
) - Note that, at first, upcoming-build will continue to inherit from 3.OLD-devel
-
-
Add Koji package signing
- On koji.chtc.wisc.edu,
/etc/koji-hub/plugins/sign.conf
; copy all the[osg-3.OLD-*]
entries to new entries, renaming the3.OLD
parts in the new enties to3.X
. - Ensure the permissions for
/etc/koji-hub/plugins/sign.conf
are 0600 apache:apache - Save the result with
etckeeper commit
- On koji.chtc.wisc.edu,
-
Update
osg-build
to use the new koji tags and targets (not by default of course)- See the Git commits on opensciencegrid/osg-build for SOFTWARE-2693 for details on how to do this
- You will be using this version of
osg-build
for some tasks, even if it hasn't been released
Do afterward, anytime before the month of the release¶
-
Create a blank
osg-3.X
SVN branch and addbuildsys-macros
package-
svn copy
buildsys-macros
from trunk and hand-edit it to hardcode the newosg_version
anddver
valuesDo the following steps for all EL versions relevant to the new series; e.g., for EL 7:
- Edit the spec file and set
dver
to7
, andosg_version
to3.X
- Run the following commands (adjust the NVR as necessary):
$ osg-build rpmbuild --el7 $ osg-koji import _build_results/buildsys-macros-*.el7.src.rpm $ osg-koji import _build_results/buildsys-macros-*.el7.noarch.rpm $ pkg=$(basename _build_results/buildsys-macros-*.el7.src.rpm) $ pkg=${pkg%.src.rpm} $ osg-koji tag-pkg osg-3.X-el7-development "$pkg"
- Edit the spec file and set
-
Do a 'real' build of
buildsys-macros
- Bump the revision in the
buildsys-macros
spec file and edit the%changelog
. Again, you will need a version of osg-build with 3.X support.
Do the following steps for all EL versions relevant to the new series; e.g., for EL 7:
- Set
dver
to 7. Commit$ osg-build koji --repo=3.X --el7
- Bump the revision in the
-
-
Update
tarball-client
bundles.ini
patches/
upload-tarballs-to-oasis
(for 3.X,foreach_dver_arch
will need to be updated for the new set of 3.Xdver_arches
)- Add relase-series specific
repos/osg-3.X-el<DVER>.repo.in
for each supported distro version (e.g.,7
,8
)
-
Populate the
bootstrap
tagsNeed to have them inherit from the 3.OLD development tags, but only packages, not builds (hence the
--noconfig
; yes, the name is weird)# set 3.OLD and 3.X as appropriate, specify any relevant dvers for el $ for el in el7; do \ for repo in 3.OLD upcoming; do \ osg-koji add-tag-inheritance --noconfig --priority=2 \ osg-3.X-$el-bootstrap osg-$repo-$el-development; \ done; \ done
-
Get the actual NVRs to tag
- I put Brian's spreadsheet into Excel and used its filtering feature to separate out:
- the packages going into 3.X.0
- package differences between each dver (eg, el7 vs el8)
- save the NVRs for each dver to a separate file, eg, pkgtotag-el7.txt and pkgtotag-el8.txt
-
Tagging:
# set 3.X as appropriate, specify any relevant dvers for el $ for el in el7 el8; do \ xargs -a pkgtotag-$el osg-koji tag-pkg osg-3.X-$el-bootstrap; \ done
(btw, xargs -a doesn't work on a Mac)
- I put Brian's spreadsheet into Excel and used its filtering feature to separate out:
-
In order to make testing easier, build the new
osg-release
andosg-release-itb
packages and promote them all the way to release, so that all the 3.X repos exist and have at least one rpm in them.
Do on the month of the 3.X.0 release¶
- Populate SVN branch and tags (as in fill it with the packages we're going to release for 3.X)
- Mass rebuild
- Don't forget to update the
empty
andcontrib
tags with the appropriate packages; remove theempty*
packages from the development tags after they've been tagged into theempty
tags
- Don't forget to update the
- Update mash
- On repo-itb
- On repo
- Update documentation here
- Update osg-test / vmu-test-runs
- They're only going to test from minefield (and eventurally testing) until the release
- Drop the
osg-3.X-elY-bootstrap
koji tags (after the successful mass rebuild only) - Update docker-software-base and any container images that are based on it
Do immediately after the 3.X.0 release¶
- Update tag inheritance on the
upcoming-build
tags to inherit from3.X-devel
instead of3.OLD-devel
Do sometime after the 3.X.0 release¶
- Do these three at the same time:
- Move the SVN
trunk
tobranches/osg-3.OLD
and movebranches/osg-3.X
totrunk
- Update the koji
osg-elY
build targets to build from and to3.X
instead of3.OLD
- Notify the software list of this change
- Move the SVN
- Update osg-test / vmu-test-runs again to add release and release -> testing tests
-
Update the docker-osg-wn-client scripts to build from
3.X
(need direct push access)- Update the constants in the
genbranches
script in thedocker-osg-wn-scripts
repo -
Update the branches in
docker-osg-wn-client
; a script like this ought to work:git clone [email protected]:opensciencegrid/docker-osg-wn-scripts.git git clone [email protected]:opensciencegrid/docker-osg-wn.git cd docker-osg-wn-scripts ./genbranches cd ../docker-osg-wn for bpath in ../docker-osg-wn-scripts/branches/*; do b=${bpath##*/} git checkout -b $b master && \ mv $bpath Dockerfile.in && \ git add Dockerfile.in && \ git commit -m "Add branch $b" done
and then run a similar script to update the existing branches Check the results before pushing, and then run
git push --all
-
Update the arrays in
update-all
andosg-wn-nightly-build
indocker-osg-wn-scripts
- Update the constants in the
-
Update the default promotion route aliases in
osg-promote
-
Update documentation again to reflect that
3.X
is now the main branch and3.OLD
is the maintenance branch
Notes on lessons learned¶
Since the upcoming
repos are not tied to an upcoming relative to 3.OLD
or 3.X
, the meaning of the upcoming
repo
changes when the new OSG series is released.
Users which have the upcoming
repo enabled before the cutover to 3.X
will find that a yum update will pull down
packages relative to the new upcoming
, relative to 3.X
, instead of the old upcoming, which was relative to
3.OLD
.
This may catch them by surprise, as it happens whether or not they update their osg-release
package to the new 3.X
version.
If it is not their intention to update to packages in the new upcoming
, users should disable their upcoming
yum
repo by the time of the new OSG series cutover, and the continuation of their old upcoming
packages will effectively
be the main osg
repo for the new 3.X
series, after they have updated their osg-release
package (usually by
installing osg-3.X-elY-release-latest.rpm
).