@@ 16,6 16,9 @@ This document describes the tasks the Org-mode maintainers have to do
and how they are performed.
* Current maintainers
+:PROPERTIES:
+:CUSTOM_ID: current-maintainers
+:END:
Carsten Dominik created Org and is still active on the list.
@@ 42,6 45,9 @@ Some files have a dedicated maintainer: just grep =;; Maintainer= in
Org's repository to find them.
* Web presence of maintainers
+:PROPERTIES:
+:CUSTOM_ID: web-presense-maintainers
+:END:
The recommended way to contact the Org maintainers is by sharing your
question, patch or bug report on [[https://orgmode.org/worg/org-mailing-list.html][the mailing list]].
@@ 59,6 65,9 @@ a table with the accounts of the current maintainers:
| Timothy | | | | |
* What is the role of a maintainer?
+:PROPERTIES:
+:CUSTOM_ID: maintainer-role
+:END:
If you speak [[https://learnxinyminutes.com/docs/elisp/][Emacs lisp]] and are a regular user of an Org file, please
consider becoming a maintainer for it: you can simply ask on the list.
@@ 80,14 89,23 @@ with a change, he can ask a maintainer to revert it.
See also this steps for [[https://orgmode.org/worg/org-contribute.html#devs][your first commit as a]] maintainer.
* What's in a release?
+:PROPERTIES:
+:CUSTOM_ID: release
+:END:
** We don't follow a release schedule
+:PROPERTIES:
+:CUSTOM_ID: release-schedule
+:END:
Org development is the work of volunteers and we cannot promise to
follow a release schedule. You can support the work of contributors
through the [[https://liberapay.com/org-mode/][Org Mode Liberapay team]].
** We don't use semantic versioning
+:PROPERTIES:
+:CUSTOM_ID: semantic-versioning
+:END:
We use the same numbering convention than semantic versioning, but we
don't follow the rules of SemVer, as expressed in [[https://semver.org][semver.org]].
@@ 102,6 120,9 @@ upgrading! All other users are welcome to read them too."
This de facto convention has been made explicit after =9.4=.
** What's in major, minor and bugfix releases?
+:PROPERTIES:
+:CUSTOM_ID: release-types
+:END:
- Major release :: The release number for a major release look like
this: =10=. Major releases are made whenever Org is in a state where
@@ 145,6 166,9 @@ Before any release, maintainers test the release against the last
three major releases of Emacs.
* Where can I track bugs, patches and updates?
+:PROPERTIES:
+:CUSTOM_ID: bug-tracker
+:END:
On [[https://updates.orgmode.org][updates.orgmode.org]], which uses [[https://github.com/bzg/woof][Woof!]] to advertize important
changes (upcoming breaking changes, new releases), confirmed bugs,
@@ 167,8 191,17 @@ contribution.
You can check the [[https://github.com/bzg/woof/blob/master/resources/md/howto.org][Woof! howto]] if you want to explore the details.
* For the release manager and core maintainers
+:PROPERTIES:
+:CUSTOM_ID: release-checklist
+:END:
** Releasing a new version of Org
+:PROPERTIES:
+:CUSTOM_ID: new-release-checklist
+:END:
*** What goes on the =bugfix= and =main= branches
+:PROPERTIES:
+:CUSTOM_ID: branches
+:END:
The [[https://git.savannah.gnu.org/cgit/emacs/org-mode.git/][git repository]] has two branches: =main= for current development and
=bugfix= for bug fixes against latest major or minor release.
@@ 182,6 215,9 @@ release suffixed by =-pre=: e.g. =9.6-pre=. The =;; Version:= header of the
==bugfix= branch is set to the last stable release, e.g. =9.5.5=.
*** For all releases
+:PROPERTIES:
+:CUSTOM_ID: merging
+:END:
The =bugfix= branch should always be merged into =main.=
@@ 191,16 227,25 @@ Always remember to set the =;; Version: [...]= metadata in =org.el=
correctly.
*** For bugfix releases
+:PROPERTIES:
+:CUSTOM_ID: bugfix-releases
+:END:
When doing a bugfix release (and only then), you shoud *NOT* merge the
=main= branch into the =bugfix= branch.
*** For minor and major releases
+:PROPERTIES:
+:CUSTOM_ID: minor-major-releases
+:END:
When doing a minor or major release, the =main= branch should be merged
into the =bugfix= branch.
*** Releasing by adding a new tag
+:PROPERTIES:
+:CUSTOM_ID: release-tags
+:END:
When doing a major and a minor release, after all necessary merging is
done, you need to tag the =bugfix= branch for the release with:
@@ 218,6 263,9 @@ We also encourage you to sign the release tags like this:
Pushing the new tag will trigger the release on GNU ELPA.
*** Preparing and annoncing the release
+:PROPERTIES:
+:CUSTOM_ID: release-announcement
+:END:
Bugfix releases don't require specific annoucements.
@@ 232,10 280,16 @@ copying the first section of =etc/ORG-NEWS= in the =Changes.org= page of
the [[https://git.sr.ht/~bzg/orgweb][orgweb]] repository.
** Synchronization Org and upstream Emacs
+:PROPERTIES:
+:CUSTOM_ID: emacs-sync
+:END:
Below it is described how Org is kept in sync with the upstream Emacs.
*** Backporting changes from upstream Emacs
+:PROPERTIES:
+:CUSTOM_ID: backporting-emacs
+:END:
Sometimes Emacs maintainers make changes to Org files. The process of
propagating the changes back to the Org repository is called
@@ 258,6 312,9 @@ There is also a [[http://git.savannah.gnu.org/cgit/emacs.git/atom/lisp/org/][fee
folder in the Emacs repository.
*** Updating the Org version in upstream Emacs
+:PROPERTIES:
+:CUSTOM_ID: org-version-emacs
+:END:
New releases of Org should be added to the [[https://git.savannah.gnu.org/cgit/emacs.git][Emacs repository]].
@@ 276,7 333,10 @@ has been tested.
Please see [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE]] in the Emacs repository for guidelines on
contributing to the Emacs repository.
-**** Where to files go
+**** Where do files go
+:PROPERTIES:
+:CUSTOM_ID: emacs-folders
+:END:
The following list shows where files in Org repository are copied to
in the Emacs repository, folder by folder.
@@ 310,11 370,17 @@ in the Emacs repository, folder by folder.
***** TODO =org-mode/testing=
**** Update =emacs/etc/NEWS=
+:PROPERTIES:
+:CUSTOM_ID: emacs-news
+:END:
Whenever a new (major) version of Org is synchronized to the Emacs
repository, it should be mentioned in the NEWS file.
** Updating the list of hooks/commands/options on Worg
+:PROPERTIES:
+:CUSTOM_ID: release-auto-documentation
+:END:
Load the =mk/eldo.el= file then =M-x eldo-make-doc RET=.
@@ 326,6 392,9 @@ Import this file into =worg/doc.org=, leaving the header untouched
Then commit and push the change on the =worg.git= repository.
** Copyright assignments
+:PROPERTIES:
+:CUSTOM_ID: copyright
+:END:
The maintainers needs to keep track of copyright assignments. Even
better, find a volunteer to do this.