|
|
@@ -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.
|
|
|
+
|
|
|
+
|
Carsten Dominik