Re: Org-mode release 7.01

[Bernt Hansen <bernt@norang.ca>]

David Maus <dmaus@ictsoc.de> writes:

> Markus Heller wrote:
>>Erik Iverson <eriki@ccbr.umn.edu> writes:
>
>>>>
>>>> I assumed I had to switch to the maint branch in order to get the 7.01
>>>> release.  How could I have done this while staying on the master branch?
>>>
>>> Basically, as long as you're on master, you'll always have the latest
>>> and greatest, which may or may not be what you want.
>
>>I am confused now.  Carsten said is his announcement that master did NOT
>>contain the 7.01 release:
>

The only thing in maint that is not in master is the change of the
version number in the sources.  You won't find the commit that sets the
version number to 7.01 on the master branch but all of the other
interesting changes are there.

> Okay, maybe these pictures will clarify: Org mode is developed in a
> branch called "master".  All new changes are done here so with A, B, C
> etc. representing changes to Org mode's source code the development
> looks like this:
>
> ,----
> |          +---+    +---+    +---+    +---+    +---+    +---+    +---+
> | [master] | A |--->| B |--->| C |--->| D |--->| E |--->| F |--->| G |--->
> |          +---+    +---+    +---+    +---+    +---+    +---+    +---+
> `----
>
> Now let's say at the source code being at patch B the stable version
> 7.01 is released.  In this case we create a new branch called "maint"
> that starts at patch B:
>
> ,----
> |          +---+    +---+    +---+    +---+    +---+    +---+    +---+
> | [master] | A |--->| B |--->| C |--->| D |--->| E |--->| F |--->| G |---> ...
> |          +---+    +---+    +---+    +---+    +---+    +---+    +---+
> |                     :
> |                     :
> |                   +---+
> | [maint]           | B |
> |                   +---+
> `----
>
> Currently "release is on maint" means that the branch [maint]
> represents the state of Org mode's sources at the time when the
> release 7.01 was made.
>
> Example: Org 7.01 was released after commit (change)
> a760c250a5585656567275c743cced6c4e652573.  The branch [maint]
> currently contains the source code as it was right after this change.[1]
> The branch [master] was at this point in time in the same state but
> has already proceeded with fresh new patches.
>
> So, 7.01 is indeed /not/ on master, because master is where all new
> things go in and has already proceeded (patch C, D etc. in the
> picture).  And [maint] will never be merged to [master], because all
> changes will be done in [master].
>
> It's the other way round: If a bug is fixed in [master] that is known
> to be present in [maint], the fix will be first made in [master] and
> than in [maint].  So if E is a fix for a bug that is present before B
> (read: in [master] and [maint]), we apply the fix in [maint], too.

It's actually easier to apply a fix that is intended to go in both
master and maint on a topic branch for the bugfix that is rooted at a
commit common to both maint and master (your [B] on the master branch, A
in the description below) and then merge that commit into both master
and maint since you only have to create the commit once.


 o -- o -- A -- o -- o -- o -- C  master
            \
             B                    maint

Create the fix (F) at A

 o -- o -- A -- o -- o -- o -- C  master
           |\
           | B                    maint
           |
           F                      bugfix

and merge the fix into maint

 o -- o -- A -- o -- o -- o -- C  master
           |\
           | B -- M               maint
           |     /
           F----/                 bugfix

and into master

 o -- o -- A -- o -- o -- o -- C -- D  master
           |\                      /
           | B -- M               /    maint
           |     /               /
           F----/               /      bugfix
            \                  /
             \----------------/

-Bernt