Re: How are we using release branches?!

On 7/31/12 6:38 AM, Max Horn wrote:
> 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 _normally_ do the release branch simultaneously with the master for
bugfixes and straightforward enhancements.  Anything that's more
involved goes on either in my own fork or a non-release branch (cf.
real-10.5-EOL), to be added when we're ready for it.

I'm distracted right now with a boatload of crap going on so I didn't
sync the current changes.  I didn't expect an audit of my methodology.

> 
> 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" ?
> 
> 

Right now master and branch_0_34 are identical, apart from the trivial
differences in the VERSION and NEWS files.

> 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

If you want us to follow some kind of specific policy, please _write it
down on the wiki_.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

------------------------------------------------------------------------------
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