COmanage Developers List

[Scott Koranda <>]

Hi,

> I've been trying to work out a git strategy for bugfixes that seems easy
> to understand and track. We've talked about it before, but I don't think
> we've settled on anything really, so here's my proposal:
> 
> (1) develop continues to be candidate changes to merge into master
>     (ie: the next minor release).

Sounds good.

> (2) Once at least one issue has been assigned to the bugfix release
>     (eg: 1.0.1), we create a new branch from the appropriate parent
>     release (ie: develop-1.0.1).

I think the approach is fine but I would change the name from
'develop-1.0.1' to something else since there is already a
branch named 'develop'. Something like 'target-1.0.1' or
'bugfix-1.0.1'.

> (3) Appropriate fixes are pushed to develop-x.y.z, NOT to develop.
> (4) When ready, develop-x.y.z is merged into master and the usual
>     release process is followed.
> (5) master is then merged into develop. (Or develop-x.y.z, I suppose
>     it doesn't matter.)

I think that approach is fine but we should be prepared that
there may be dead-end changes in a branch that should not be
merged into devlop, or there may be a mixture of things we
want to merge it and dead-end changes.

> I think this avoids cherry picking as part of the process, which seems
> cleaner to me.

We may need cherry picking to grab commits when a branch has
both things we want to evolve and dead-end changes.

Thanks,

Scott

> 
> Thoughts?
> 
> Thanks,
> 
> -Benn-