160 lines
5.7 KiB
Plaintext
160 lines
5.7 KiB
Plaintext
RELEASE MANAGEMENT
|
|
|
|
ViewVC rolls releases from release branches associate with each minor
|
|
version of the software. For example, the 1.1.0 is rolled from the
|
|
1.1.x branch. The same is true for the 1.1.1, 1.1.2, ... releases.
|
|
|
|
|
|
A. Creating Release Branches
|
|
============================
|
|
|
|
Primary ViewVC development occurs on the trunk, with bugfixes and
|
|
compatible features being backported to release branches as
|
|
appropriate. When, however, the need arises to create a new release
|
|
branch, here's the process (M, N, X, and Y below represent integral
|
|
major, minor, and patch version numbers, and are not literal):
|
|
|
|
1. Create the release branch as a copy of the trunk@HEAD (the
|
|
lower-case "x" in the branch name is literal):
|
|
|
|
svn cp -m "Branch for X.Y release stabilization." . ^/branches/X.Y.x
|
|
|
|
2. On the trunk, update the following files to reflect the new
|
|
version which trunk will be progressing towards:
|
|
|
|
CHANGES: Add stub section for new release.
|
|
INSTALL: Update example configuration.
|
|
lib/viewvc.py: Update "__version__" value.
|
|
docs/upgrading-howto.html: Add stub section for new release.
|
|
docs/template-authoring-guide.html: Update to reflect new release.
|
|
docs/release-notes/M.N.0.html: Add a new stub file.
|
|
|
|
Commit these changes:
|
|
|
|
svn ci -m "Trunk is now progressing toward version M.N."
|
|
|
|
|
|
B. Publishing Releases
|
|
======================
|
|
|
|
There is a script, `tools/make-release', which creates a release
|
|
directory and the various archive files that we distribute. All other
|
|
steps required to get a ViewVC release out of the door require manual
|
|
execution (currently by C. Michael Pilato). Those steps are as
|
|
follows:
|
|
|
|
Checkout a working copy of the release branch for the release you
|
|
intend to roll, and in that working copy, perform the following steps
|
|
(X, Y, and Z below represent integral major, minor, and patch version
|
|
numbers, and are not literal):
|
|
|
|
1. Review any open bug reports:
|
|
|
|
http://viewvc.tigris.org/servlets/ProjectIssues
|
|
|
|
2. Ensure that the file 'docs/upgrading.html' describes all user
|
|
visible changes for users of previous releases of ViewVC. (Any
|
|
changes here should be made on the trunk and backported to the
|
|
branch.) NOTE: This step should not be necessary for patch
|
|
releases.
|
|
|
|
3. Verify that copyright years are correct in both the license-1.html
|
|
file and the source code.
|
|
|
|
4. Update and commit the 'CHANGES' file, using any available crystal
|
|
balls or other forward-looking devices to take a stab at the
|
|
release date.
|
|
|
|
5. Test, test, test! There is no automatic testsuite available. So
|
|
just run with permuting different `viewvc.conf' settings... and
|
|
pray. Fix what needs fixin', keeping the CHANGES file in sync
|
|
with the branch.
|
|
|
|
6. At this point, the source code committed to the release branch
|
|
should exactly reflect what you wish to distribute and dub "the
|
|
release".
|
|
|
|
7. Update your release branch working copy to HEAD.
|
|
|
|
svn up
|
|
|
|
8. Edit the file 'lib/viewvc.py' and remove the "-dev" suffix from
|
|
__version__. The remainder should be of the form "X.Y.Z", where X,
|
|
Y, and Z are positive integers.
|
|
|
|
*** Do NOT commit this change. ***
|
|
|
|
9. "Peg" the contributed templates externals definition to the
|
|
current HEAD revision:
|
|
|
|
svn pedit svn:externals .
|
|
|
|
(squeeze "-rBASE_REV", where BASE_REV is the current HEAD revision
|
|
number, between 'templates-contrib' and the target URL).
|
|
|
|
*** Do NOT commit this change. ***
|
|
|
|
10. Tag the release:
|
|
|
|
svn cp -m "Tag the X.Y.Z final release." . ^/tags/X.Y.Z
|
|
|
|
This will create a copy of the release branch, plus your local
|
|
modifications to the svn:externals property and lib/viewvc.py
|
|
file, to the tag location.
|
|
|
|
11. Revert the changes in your working copy.
|
|
|
|
svn revert -R .
|
|
|
|
12. Go into an empty directory and run the 'make-release' script:
|
|
|
|
tools/make-release viewvc-X.Y.Z tags/X.Y.Z
|
|
|
|
13. Verify the archive files:
|
|
|
|
- do they have a LICENSE.html file?
|
|
- do they have necessary include documentation?
|
|
- do they *not* have unnecessary stuff?
|
|
- do they install and work correctly?
|
|
|
|
14. Upload the created archive files (tar.gz and zip) into the Files
|
|
and Documents section of the Tigris.org project, and modify the
|
|
CHECKSUMS document there accordingly:
|
|
|
|
http://viewvc.tigris.org/servlets/ProjectDocumentList?folderID=6004
|
|
|
|
Also, drop a copy of the archive files into the root directory of
|
|
the viewvc.org website (unversioned).
|
|
|
|
15. Update the Tigris.org website (^/trunk/www/index.html) to refer to
|
|
the new release files and commit.
|
|
|
|
svn ci -m "Bump latest advertised release."
|
|
|
|
16. Back on the release branch, edit the file 'lib/viewvc.py' again,
|
|
incrementing the patch number assigned to the __version__
|
|
variable. Add a new empty block in the branch's CHANGES file.
|
|
Commit your changes:
|
|
|
|
svn ci -m "Begin a new release cycle."
|
|
|
|
17. Edit the Issue Tracker configuration options, adding a new Version
|
|
for the just-released one, and a new Milestone for the next patch
|
|
(and possibly, minor or major) release. (For the Milestone sort
|
|
key, use a packed integer XXYYZZ: 1.0.3 == 10003, 2.11.4 == 21104.)
|
|
|
|
http://viewvc.tigris.org/issues/editversions.cgi?component=viewvc&action=add
|
|
http://viewvc.tigris.org/issues/editmilestones.cgi?component=viewvc&action=add
|
|
|
|
18. Send to the announce@ list a message explaining all the cool new
|
|
features.
|
|
|
|
http://viewvc.tigris.org/ds/viewForumSummary.do?dsForumId=4253
|
|
|
|
19. Post a new release notification at Freecode.
|
|
|
|
https://freecode.com/projects/viewvc/releases/new
|
|
|
|
20. Merge CHANGES for this release into the CHANGES file for newer
|
|
release lines and commit.
|