83 lines
2.9 KiB
Org Mode
83 lines
2.9 KiB
Org Mode
|
|
# -*- 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. Only the fix to the bug is
|
|
bundled into a release, without the main development work going on in
|
|
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 switch 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 been 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.
|
|
|
|
|