+1 to what Anthony said.
> On Nov 13, 2019, at 8:07 AM, Anthony Baker wrote:
>
> The expectation is that master always points to the latest release (in this
> case 1.10.0). There’s a rel/v1.9.2 tag already—what more is needed? We
> don’t need the release branch since further patches can be
Great, that sounds like a reasonable expectation & also the simplest solution!
I cleaned up a few release branches that should have already been deleted. No
further action is needed.
-Owen
> On Nov 13, 2019, at 8:07 AM, Anthony Baker wrote:
>
> The expectation is that master always points to
The expectation is that master always points to the latest release (in this
case 1.10.0). There’s a rel/v1.9.2 tag already—what more is needed? We don’t
need the release branch since further patches can be branched from that tag.
IOW, I don’t understand why we should to overwrite master with
I think we should look at other examples of git-flow merge practices for
this kind of thing. We can't be the only project that does this.
But I vote for a merge commit
On Tue, Nov 12, 2019, 16:20 Owen Nichols wrote:
> It’s been a few weeks since 1.9.2 release was announced, and there is
> still
It’s been a few weeks since 1.9.2 release was announced, and there is still no
record of it on master. What should we do?
A) never record 1.9.2 on master; instead keep the most recent release/1.9.x
branch around indefinitely (normally we delete release branches after pushing
them to master).
B
