[mapserver-dev] Re: applying bugfixes to multiple branches

[thomas bonfort]

Thinking about this a bit more, I think we should stop editing
HISTORY.TXT in stable branches, as the commit messages are necessary
and sufficient to create the Changelog for our point releases.
HISTORY.txt would only be edited in master, and contains the features
worthy enough of being announced during a major release. If folks are
ok with this, we can start working this way from now onwards (our
coming stable releases might require a bit of hand-editing of the
generated changelog).

--
thomas

On Fri, Apr 13, 2012 at 19:54, Stephan Meißl <stephan at meissl.name> wrote:
> Thomas, all,
>
> finally I started enjoying git and github :) and I hope I used it the
> right way. Thanks for the detailed instructions.
>
> After going through it I agree that we should think of an alternative to
> the HISTORY.TXT and the proposed solution looks good to me.
>
> One question to github: Adding an issue I was wondering if there
> shouldn't be milestones 6.0.3, 5.6.9, etc. under "Open" and I guess
> 6.0.2, etc. should go under "Closed"?
>
> cu
> Stephan
>
>
> On Wed, 2012-04-04 at 22:01 +0200, thomas bonfort wrote:
>> I've started a wiki page with some good practices. Please feel free to
>> add or ammend:
>>
>> https://github.com/mapserver/mapserver/wiki/WorkingWithGit
>>
>> Steve pointed out that this workflow for release branches will
>> consistently provoke a merge conflict on our HISTORY.TXT file, as this
>> file diverges in each release branch. Although fixing this conflict is
>> pretty simple (cut the conflicting line and paste it at the beginning
>> of the changes for the current release), it would be nice to start
>> thinking on how we can rely on commit logs for generating a release
>> history rather than maintaining this file.
>> One solution would be to add a special tag in the commit message that
>> we can grep through when creating the release notes. There are two
>> kind of messages that must be highlighted:
>>
>> - fixes to the stable branches: every single bugfix to the repo should
>> contain a commit with this tag.
>> - changes to master: a tag would be added for commits/pushes that add
>> a new feature or a change worthy of appearing in the release notes.
>>
>> the syntax used for these tags could be ==rel== and ==tag== , e.g.:
>>
>> ==rel== fix divide by 0 in mapfoo.c (#1234)
>> or
>> ==tag== add support for SVG symbols (rfc99)
>>
>> thoughts?
>>
>> --
>> thomas
>>
>> On Wed, Apr 4, 2012 at 19:57, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> > Btw,
>> > This proposed change isn't mandatory, we can quit using it if we find
>> > out it's too cumbersome in the long run. I do think we should give it
>> > a try as there are many times we only fix in trunk whereas fixing in
>> > the previous release branch could be just as easy with this method.
>> > The "downside" is that until we decide wether we want to keep working
>> > this way, all changes to stable branches should be done this way.
>> >
>> > --
>> > thomas
>> >
>> > On Wed, Apr 4, 2012 at 19:34, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> >> Hi devs,
>> >> Following the workflow described here
>> >> http://www.net-snmp.org/wiki/index.php/Git_Workflow,
>> >> I've setup a script in our repository that changes the way fixes
>> >> should be applied to stable branches. The aim is to simplify the task
>> >> of applying a fix to multiple branches. So, in the case where a fix
>> >> needs to be applied to more than just master, this is the workflow to
>> >> use:
>> >>
>> >> - make sure you have an uptodate clone, and that your master and
>> >> stable branches don't have any uncommited or unpushed changes
>> >>
>> >> - pick the oldest branch your fix applies to (or that you are willing
>> >> to support), for the example let's say it is branch-5-4
>> >>
>> >> - set your working copy to this branch:
>> >>  git checkout branch-5-4
>> >>
>> >> - create a temporary branch for your fix
>> >>  git checkout -b bug1234
>> >>
>> >> - code, test your fix, etc...
>> >>  git add changd_file.c
>> >>  git commit -m "fix bug 1234, blabla"
>> >>
>> >> - once the fix is ready merge it into branch-5-4
>> >>  git checkout branch-5-4
>> >>  git merge bug1234
>> >>
>> >> - you are now ready to apply this fix in the newer release branches. A
>> >> script automates this process:
>> >>  sh stablemerge.sh
>> >>
>> >> - what the script does is iteratively merge 4-10 into 5-0, then 5-0
>> >> into 5-2, etc, up till 6-0 into master. This means your fix is
>> >> propagated to all newer branches down into master.
>> >>
>> >> - for more complex fixes and/or very old branches, the fix will likely
>> >> not always apply cleanly from one branch to the next. You'll be
>> >> returned back to your shell with a message indicating which file has a
>> >> conflict and asked to manually edit it to resolve. Once you've fixed
>> >> the conflict, commit your edited file, and rerun the stablemerge.sh
>> >> script to continue propagating your updated fix to newer branches.
>> >>
>> >> Please try to avoid copy-pasting a fix in multiple branches to
>> >> accomplish the same task, as it will result in conflicts the next time
>> >> someone runs the process.
>> >>
>> >> Don't hesitate to ping me if you need help with this.
>> >>
>> >> best regards,
>> >>
>> >> thomas
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>