How are we using release branches?!

Hi there,

I am a bit confused by this commit:

  Alexander Hansen master * r9a31ce1 / NEWS : Start listing features for next release. - http://git.io/HuaDZw

(Before I go on: This is not a critique, but rather honest puzzlement, and I am extremely grateful to akh for the hard work he is investing into Fink!)

Here is the thing: This commit on the master branch describes changes in the NEWS file for release 0.34.2. Yet we also have a release branch for the 0.34.x series: branch_0_34. This branch neither contains the NEWS file change, nor does it contain several of the changes listed in the NEWS file.

So, I am somewhat unclear how development is meant to proceed from here on. Which of these is the case:

1) We simply have abandoned using release branches, 0.34.2 and future releases will be directly from master, whatever it contains.

1b) As a variation, the branch label "branch_0_34" is kept but moved over to point to the current master HEAD commit.

2) We are still using branch_0_34. Somebody will soon determine which master commits are "relevant" for 0.34.2, and those will be manually cherry picked into the release branch.

3) Something else?


I am a bit puzzled by this. And if it 2), I am also a bit worried about this "un-gittish" approach. It is somewhat problematic because it would invalidate most of the testing that's been done with those commits, as they would be re-assembled in a different way to what was there before. And it is easy to forget a "relevant" commit... Anyhow, how would we decide which commits are "relevant" ?


For comparison, the model I usually follow and have learned to use in other projects works using merge as follows. Perhaps it is worth a moment to think about this; perhaps it would also be good for Fink. Note that this is similar to the workflow used by git, and also similar to what the Mercurial devs suggest.

Here, bug fixes that are also for the release go first into the release branch, which then is merged into master. On the other hand, new features not intended for the next minor release go only to master. Ideally, they also first go to feature branches; and "putting them into master" then is just a merge commit. If one later decides that the feature should also go into the "stable" release branch, then no cherry picking is necessary, but rather the feature branch is also merged into the stable branch.

The big advantage then is that the master commit *always* contains all commits from the release branch. This avoids a classic problem, where a bugfix is applied to the release branch, but by accident is not applied to the master branch.

Concrete, this means to make a bug fix for a feature already present in the release, I would do this>

 git checkout release_0_3_4
 ... edit files ...
 git commit ...
 git push
 # Now make sure master also has the fix
 git checkout master
 git merge release_0_3_4
 # possibly have to cleanup merge conflicts at this point...
 git push


While a new feature, or a fix for a feature not yet in the stable release, would just go to master:

  git checkout master
  ... edit ...
  git commit ...
  git push

A new feature, or just any complex modification, would be developed on a branch:

  git co -b my-feature
  ... edit and commit as needed...
  git push fingolfin   # push to my repos
  ... let people review the changes if appropriate ...
  
Once happy with the feature, I either merge it into both stable and master (if it is meant for 0.34)

  git checkout release_0_3_4
  git merge my-feature
  git checkout master
  git merge release_0_3_4
  git push

or just master:

  git checkout master
  git merge my-feature
  git push


Finally, for this to work well, some initial work is needed when setting up the release branch.

  # Create release branch
  git co -b release_0_3_5 master
  # Setup new version
  echo "0.35.0.git" > VERSION
  git add VERSION
  git commit -m "Prepare for 0.35.x"
  # Switch back to master, ensure VERSION is different
  git co master
  echo "0.35.99.git" > VERSION
  git add VERSION
  git commit -m "Master post 0.35.x"
  # Merge
  git merge release_0_3_5
  # Resolve conflict in VERSION
  echo "0.35.99.git" > VERSION
  git add VERSION
  git commit -m "Merge release branch into master"

Note that this is a very uniform business, and could be scripted, so the above could become just this:
  ./create-release-branch 0.3.5

other than that, the NEWS file might sometimes conflict, with 0.35 vs. post-0.35 additions, but that should be trivial to resolve each time.



Cheers,
Max
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core