forked from mirrors/org-mode
83 lines
2.9 KiB
Plaintext
83 lines
2.9 KiB
Plaintext
|
|
||
|
# -*- 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.
|
||
|
|
||
|
|