On 11 February 2016 at 03:23, Bill Moseley <[email protected]> wrote:

> Developer 1 creates their branch, updates code in Foo::Schema, "dzli
> release" it and now it is version 1.5.   They update Foo::App to depend on
> Foo::Schema 1.5.   Then commit to their branch.
>
> The problem is when Developer 2 branches at the same time as Developer 1.
>   Their branch does not have Developer 1's changes to Foo::Schema yet.
> So, when they later dzil release and, say, create version 1.6, that version
> is missing the changes from Developer 1.  It's not backwards compatible.
>
> Developer 2 can update Foo::App to depend on version 1.6 and merge back to
> master, but the version on DarkPAN is missing Developer 1's changes.
>

That sounds like a kind of self-abuse caused by the "publish a release on a
branch" goal.

That seems wrong to me.

Features should be folded back into master first, master should be tagged
"1.5", and *that* commit should be built and released.

That way "master" becomes a synchronization point that all users have to
get a conceptual lock on before releasing.

An alternative option is designating one team member the release manager,
and when QA approves a feature branch, the designated release manager at
that time deals with final packaging fixes and releases, and so your
problem vanishes because none of the "developer 2 did a release without the
right changes in it" problem.

I know all the github flow and similar such "flow" concepts on the web
advocate that master is something that happens *after* release, but that's
really against the design of git. Git is designed for master to be the
working branch, not an "archive stream of releases".


-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL



-------------------------------------------
Dist::Zilla
Archives: https://www.listbox.com/member/archive/139292/=now
RSS Feed: https://www.listbox.com/member/archive/rss/139292/21080831-4b8afa6a
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21080831&id_secret=21080831-2b0ee212
Powered by Listbox: http://www.listbox.com

Reply via email to