fenics team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

The PETSc developers have laid out their approach, which includes
fixes to releases:

    https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git

Maybe we should follow their approach, and piggy back on their
easy-to-follow development model documentation? Over time we can
evolve our own workflow if required.

Garth

On 11 April 2013 02:32, Florian Rathgeber <florian.rathgeber@xxxxxxxxx> wrote:
> On 10/04/13 16:29, Anders Logg wrote:
>> On Wed, Apr 10, 2013 at 02:55:13PM +0200, Martin Sandve Alnæs wrote:
>>> I've just pushed a critical bugfix to ufl on bitbucket, which should
>>> be backported (cherry-picked) to 1.2. What's the procedure for this
>>> now? Do we apply patches to the old lp series? Is there a 1.2 git
>>> branch I can cherry-pick directly to?
>>
>> There's no such branch. But if we decide to follow the gitflow model,
>> we should create a new branch called 'develop' inside the ufl
>> repository (the branch 'master' already exists).
>
> Note that you can very easily resurrect any revision as any branch:
> $ git branch <branch-name> <revision>
>
> But gitflow doesn't have long lived release branches:
>
>> All releases should be made from the 'master' branch and all
>> development in the 'develop' branch. Before each release, one branches
>> off 'develop' via a release branch and then into 'master'. Then after
>> the release, the release branch gets removed.
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>
> The release branch only lives for as long as it takes to finalise the
> release, at which point it is merged into master and that revision of
> master is tagged with the release and the branch removed.
>
>> What is needed for a fix like this is to make a temporary 'hotfix'
>> branch off 'master'. So my suggestion would be to
>>
>> 1. Create the 'develop' branch (from 'master')
>>
>> 2. Create a branch 'hotfix-1.2.1' from master
>>
>> 3. Fix the bug there (cherry pick from 'develop')
>>
>> 4. Merge the fix into 'develop' and 'master'
>>
>> 5. Remove the hotfix branch
>>
>> Steps 3-4 will be a bit different since you already made the fix in
>> 'master'.
>
> I wouldn't retrospectively try to hammer history into gitflow shape.
> Instead I would tag e21d9f6 as release 1.2.1 and start gitflow from
> there i.e. make this also the tip of the dev branch (so this revision
> will the the last revision ever where dev and master will point to the
> same revision) and only work on dev from then on.
>
> # assuming you're on e21d9f6
> $ git tag 1.2.1  # tag the current revision
> $ git branch dev # create a new branch starting at the current revision
> $ git push --tags -u origin dev
>
> Florian
>
>> --
>> Anders
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>