altf4arnold/datatracker
1
0
Fork 0
Code Issues Pull requests Actions 3 Packages Projects Releases Wiki Activity

With the secretariat now using the secr/ code deployed with the datatracker, there is no concern any more about divergence between production secretariat and datatracker secretariat code, and no need to have two different patch numbering systems for secretariat patches and other patches. Removing the secretariat-specific patch section.

Browse source 
- Legacy-Id: 6673
This commit is contained in:
Henrik Levkowetz 2013-11-06 22:16:09 +00:00
parent 2c5e7fd7f4
commit 5067b6e51a
1 changed files with 0 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
INSTALL
View file

@ -97,27 +97,6 @@ process should be used:
`General Instructions for Deployment of a New Release`_ .
Installing a Secretariat Release
================================
Secretariat releases are based on a regular tagged release, but contain
updated code in the ietf/secr/ tree. They are named with a trailing
'.secr<N>' version number. If the tagged release is for instance 4.42, the
first secretariat release based on that would have release number 4.42.secr1,
and the second secretariat release based on it would be numbered 4.42.secr2.
Secretariat releases are deployed in the same manner as regular releases, with
the addition that patches made to the regular release needs to be picked up
and applied. Assuming we'releasing 4.42.p1.secr2, then after we've cd'd into
the release diretory to run migrations, we'd also run a patch step to pick
up the current patches to the current production release, which is pointed
to by ../web::
/a/www/ietf-datatracker/4.42.p1.secr2 $ svn diff ../web/ | patch -p2
Assuming that runs without error messages, the deployment is continued as
usual, with re-pointing the symlink and restarting apache.
Additional Version-Specific Instructions
========================================