mirror of
https://git.savannah.gnu.org/git/emacs/org-mode.git
synced 2024-09-29 20:37:51 +00:00
Start new file which describes maintainer tasks
This commit is contained in:
parent
912ca55601
commit
b3c079e97b
82
README_maintainer
Normal file
82
README_maintainer
Normal file
|
@ -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.
|
||||
|
||||
|
Loading…
Reference in a new issue