From b3c079e97bae7aa6764578ce54b83b7389ffd6fb Mon Sep 17 00:00:00 2001 From: Carsten Dominik Date: Fri, 15 Oct 2010 12:36:36 +0200 Subject: [PATCH] Start new file which describes maintainer tasks --- README_maintainer | 82 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 README_maintainer diff --git a/README_maintainer b/README_maintainer new file mode 100644 index 000000000..37d1494e7 --- /dev/null +++ b/README_maintainer @@ -0,0 +1,82 @@ + +# -*- mode:org -*- + +#+title: Maintainer tasks +#+startup: indent + +This document describes the tasks the Org-mode maintainer has to do +and how they are performed. + + +* Releases + +** Main releases + +The release number for main releases look like this: =7.13= + +Main releases are made whenever Org is in a state where the feature +set is consistent and we feel that the features that are implemented +is something we want to support in the future. + +A major release turns the current state of the master branch into a +release. The release process is a single make command: + +: make release TAG=7.13 + +** Minor releases + +The release number for minor releases look like this: =7.13.01= + +Minor releases are small amends to main releases. Usually they fix +bugs discovered in a main release. The only yhe fix to the bug is +bundled into a release, without the main development work going on on +the master branch. Since the big fix will also be needed in the +master branch, usually the fix is made in master and then +cherry-picked into maint. When this is done, a release is made from +maint with this command: + +: make fixrelease TAG=7.13.01 + +* Synchonization with Emacs + +This is still a significant headache. Some hand work is needed here. + +Emacs uses bzr, I cannot bring myself to swith from git to bzr for the +development version of Org-mode. So the way I have been doing things +is this: + +1. I watch the Emacs diffs for changes made by the maintainers of + Emacs in the org-mode files in Emacs. Any changes that come up + there, I merge into the development version of Org-mode. + Occasionally I do not do this, if I do not agree with a change. + The changes go into Org /without/ a ChangeLog-like entry in the + commit message. The reason for this is that we will later generate + a ChangeLog file from our commit messages, and I do not want double + Change entries in the Emacs ChangeLog file. + +2. When I have made a release (usually I wait for the minor releases + to stabilize), I copy org files into the Emacs repository. Yes, I + do not merge, I copy. This has ben the source of some problems in + the past - but I have not had the patience to work out a better + mechanism. + + Careful: Copy org.texi and orgcard.tex into the right places, and + also copy the lisp files with *two exceptions*: Do *not* copy + /org-colview-xemacs.el/ and /org-install.el/. The former does not + belong in Emacs. And the latter would actually be harmful because + Emacs generates its own autoloads. The Emacs distribution contains + an empty org-install.el, so that users can have =(require + 'org-install)= in .emacs with no ill effects. So if you were to + copy org-install.el, you would overwrite that empty placeholder + file. + +3. Generate the ChangeLog entries + + For this, I do in the org-mode git repository + + : UTILITIES/make_emacs_changelog release_7.02.05..release_7.03.02 + + This will spit out the ChangeLog entries that need to go into the + ChangeLog file in the lisp/org directory in Emacs. + +