]> git.sur5r.net Git - bacula/bacula/commitdiff
Add first cut of a release procedure
authorKern Sibbald <kern@sibbald.com>
Sat, 26 Nov 2011 11:47:31 +0000 (12:47 +0100)
committerKern Sibbald <kern@sibbald.com>
Sat, 20 Apr 2013 12:50:18 +0000 (14:50 +0200)
bacula/release/ReleaseProcedure.txt [new file with mode: 0644]

diff --git a/bacula/release/ReleaseProcedure.txt b/bacula/release/ReleaseProcedure.txt
new file mode 100644 (file)
index 0000000..e359a3d
--- /dev/null
@@ -0,0 +1,60 @@
+
+These are the steps to complete for making a new release.
+
+1. Ensure that the previous release had a tag pushed. If
+   not create one at the prior release point and push it
+   to the repos.
+
+2. Update the ChangeLog using release/git2changelog.pl Release-5.2.x..HEAD >1
+
+3. Edit 1 into ChangeLog ensuring to mark the previous release
+   Version number prior to adding the new ChangeLog output.
+
+4. Edit the ReleaseNotes. Be sure not to change anything in the
+   prior version (typos are OK).  This sometimes means duplicating
+   text, but it is far better to have a complete history.
+   Terminate the previous release with a line of all =====,
+   and ensure that the previous release version is properly
+   defined.  Then add the new release section.  Point out
+   the need to review prior releases if changing major versions.
+
+5. Update the version and date.
+
+6. Update the po files (cd po; make update-po).  Correct any
+   problems and re-run until correct.
+
+7. Update the docs. Make sure they have the correct date, and
+   that the new docs are uploaded to bacula.org
+
+8. Make sure everything is pushed including the docs.
+
+9. Run a full regression test (./nightly-all) on as many
+   platforms as possible.
+
+10. Check the CDash Bacula output pages to make sure there are
+    no overlooked problems.
+
+11. Cut the release (i.e. make the .tar.gz files) by copying
+   the release directory out of the build tree, ensuring that
+   your config file is properly set, and that your signing
+   key is properly setup, and running the ./makeall script.
+
+12. Ensure that the Windows builds were done properly.
+
+13. detar the main bacula source release
+
+14. Run a regression on the detared file (ensures that all files
+    are actually in the tar and that it is not corrupt).
+
+15. push the tags (once pushed they can be corrected but it is more
+    complicated than simply re-running the ./makeall script)
+
+16. Upload the release files to Source Forge.
+
+17. Update the release version and date on the main bacula.org page
+
+18. Update the news item to announce the release.
+
+19. Send the release announcement to the users, devel, and announce 
+    mailing lists.
+