curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: Change master to be CURATOR-3.0?
Date Tue, 02 May 2017 19:20:34 GMT
FYI this may be the only reasonable thing to do: <>

git branch -m master master-2.0
git push origin :master
git push origin master-2.0
git checkout CURATOR-3.0
git checkout -b master
git push origin master

I don't know what this does to old forks though. When I get a chance I'll play around with
a dummy Github project.


> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <> wrote:
> I'd like to pick this up again...
> ZK 3.5 is now at beta and will soon be the release/master version. Also, I notice more
and more CURATOR-3.0 only changes. Sooner or later, CURATOR-3.0 needs to become master. 
> Whenever we do it, though, there's the problem of _how_ to do. I've been searching and
there doesn't seem to be a clean way to do it. Most of the solutions I've seen involve doing
a "git push -f" eventually which is pure evil as I understand it.  Anyone know the best way
to do it?
> What we have now:
> * master (represents the Curator 2.x line)
> * CURATOR-3.0 (represents the Curator 3.x line)
> What we should have:
> * master-2.0 (what was master)
> * master (represents the Curator 3.x line)
> Thoughts?
> -JZ
>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <>
>> Eventually, it will be the main branch when ZooKeeper 3.5 finally exits alpha/beta.
So, I thought that we should reflect that in our repo. Also, we're starting to get changes
that only apply to CURATOR-3.0 branch. But, then, it might screw up our current merge strategy
so it could be a bad idea. 
>> -Jordan
>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <> wrote:
>>> What's the motivation? Is it just that fixes are more likely to be 3.X
>>> centric now, and it's more logical to create PRs to master?
>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>>>> wrote:
>>>> I've been thinking it might be time to make the CURATOR-3.0 branch master.
>>>> Thoughts? I'm not sure the best way to do this from a git perspective. If
>>>> anyone has suggestions I'd appreciate it.
>>>> -Jordan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message