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:

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.


,----
| +---+    +---+    +---+    +---+    +---+    +---+    +---+
| | A |--->| B |--->| C |--->| D |--->| E |--->| F |--->| G |---> ...
| +---+    +---+    +---+    +---+    +---+    +---+    +---+
|            :                          :
|            :                          v
|          +---+                      +---+
|          | B |----------------------| E'|--->
|          +---+                      +---+
`----

If people use a stable version (e.g. Release 7.01) we can provide
fixes for bugs in this version.

More details on this topic especially for Git can be found in:

The Git Community Book
http://book.git-scm.com/

-or-

Loeliger, Jon: Version Control with Git.  O'Reilly 2009.
(my favorite)

HTH,
  -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de