@@ 108,9 108,31 @@ Note that before =Org 9.5=, versions like =9.3=, =9.4=, etc. were
really /major/ ones. This was confusing for some users, especially
those who expect Org to follow semantic versioning conventions.
* Where can I track bugs, patches and updates?
** Git workflow
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,
submitted patches and help requests.
Here is a super-quick Woof! primer:
- Patches sent to the mailing list are automatically tracked.
- To mark a patch as applied, you just need to place =Applied= at the
beginning of your reply to the patch submitter.
- Bugs reported to the list are /not/ tracked until some confirms them
by placing =Confirmed= at the beginning of a line in his reply to the
You don't much more: confirming bugs is a critical 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
** Releasing a new version of Org
*** Git workflow
The git repository has two branches:
@@ 121,14 143,14 @@ Bug fixes always go on =bugfix= then are merged on =main=.
New features always go on =main=.
** Major release: merging main into bugfix
*** Major release: merging main into bugfix
All commits in the =bugfix= branch should always be merged into the
=main= branch. Both minor and major releases are done from the =bugfix=
branch. When doing a major release, the =main= branch is merged into
the =bugfix= branch.
** Tagging the release
*** Tagging the release
When doing a major and a minor release, after all necessary merging is
done, tag the _bugfix_ branch for the release with:
@@ 145,11 167,11 @@ We also encourage you to sign release tags like this:
The GNU ELPA packages is built from the *bugfix* branch.
* Synchronization Org and upstream Emacs
** Synchronization Org and upstream Emacs
Below it is described how Org is kept in sync with the upstream Emacs.
** Backporting changes from upstream Emacs
*** Backporting changes from upstream Emacs
Sometimes Emacs maintainers make changes to Org files. The process of
propagating the changes back to the Org repository is called
@@ 171,7 193,7 @@ backported. The should also be done for the =main= branch.
There is also a [[http://git.savannah.gnu.org/cgit/emacs.git/atom/lisp/org/][feed]] to keep track of new changes in the =lisp/org=
folder in the Emacs repository.
** Updating the Org version in upstream Emacs
*** Updating the Org version in upstream Emacs
New releases of Org should be added to the [[https://git.savannah.gnu.org/cgit/emacs.git][Emacs repository]].
@@ 190,12 212,12 @@ 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 to files go
The following list shows where files in Org repository are copied to
in the Emacs repository, folder by folder.
- =org.texi= :: Copy to =emacs/doc/misc=. It may be necessary to replace,
~@include org-version.inc~ with ~@set VERSION 9.0.9~ or similar.
@@ 203,7 225,7 @@ in the Emacs repository, folder by folder.
- =orgcard.tex= :: Copy to =emacs/etc/refcards=. Make sure that
~\def\orgversionnumber~ and ~\def\versionyear~ are up to date.
- =styles/*= :: Copy to =emacs/etc/org=.
@@ 214,21 236,21 @@ in the Emacs repository, folder by folder.
- =ORG-NEWS= :: Copy to =emacs/etc=
- Copy =*.el= files to =emacs/lisp/org=, except =org-loaddefs.el=!
- You should create =org-version.el= in =emacs/lisp/org=. The file is
created when you =make= Org.
**** TODO =org-mode/testing=
***** TODO =org-mode/testing=
*** Update =emacs/etc/NEWS=
**** Update =emacs/etc/NEWS=
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
** Updating the list of hooks/commands/options on Worg
Load the =mk/eldo.el= file then =M-x eldo-make-doc RET=.
@@ 239,7 261,7 @@ Import this file into =worg/doc.org=, leaving the header untouched
Then commit and push the change on the =worg.git= repository.
* Copyright assignments
** Copyright assignments
The maintainers needs to keep track of copyright assignments. Even
better, find a volunteer to do this.