[RFC] client-go versioning about client-go

[lavalamp]

OK, I think we should just do this and accept the consequences.

• Let's ditch the individual folders.
• Head of the master branch will track head of the kubernetes main repo.
• We'll move the 1.4 client into a 1.4 branch. (and tag it as 1.4.0)
• We'll cut new branches/tags when we've accumulated enough changes.

Consequence:

• go get will give unstable development versions (!!!!)
• Users must vendor to get a stable client
• ...or they could use gopkg.in and rewrite our internal import statements.

I don't think we have a better option at the moment. I know the go team is looking at this, but we can't wait for go1.8 or whatever. We can make improvements in the future.

I've been trying to think of a way to improve on this with git submodules or other trickery, but haven't managed to think of anything yet.

[caesarxuchao]

@lavalamp @thockin @jimmidyson @timoreimann

Please cc whoever you think will be interested.

Is there a SIG I can @ here?

[lavalamp]

@kubernetes/sig-api-machinery is the owning sig, I think.

[lavalamp]

It is really irritating that the version has to be in the import paths that client-go itself uses. (It's good for it to be in the paths that users use.) This seems to be a defect with go.

[lavalamp]

We're already running an nginx server to serve the go import meta lines. So this wouldn't be too much worse operationally.

[lavalamp]

We should decide on something that will work for all the go packages in the kubernetes org, since we're going to be splitting more and more of them out.

[timoreimann]

Another approach that comes to my mind is to run a single repository, maintain different major versions in separate branches, and have users vendor according to their needs. I'm mostly familiar with govendor and glide, but at least these two are able to track branches.

The downside is that users are effectively required to use a vendor tool. However, if they do anyway (which I assume is slowly becoming the dominating case), it'll be much easier to manage client-go compared to gopkg.in as there will be no need to update import paths between major version upgrades.

[k8s-oncall]

Kubernetes itself is unfortunately using godep, which unfortunately doesn't
have that capability afaik. :(

On Thu, Oct 6, 2016 at 5:35 PM, [email protected] wrote:

Another approach that comes to my mind is to run a single repository,
maintain different major versions in separate branches, and have users
vendor according to their needs. I'm mostly familiar with govendor and
glide, but at least these two are able to track branches.

The downside is that users are effectively required to use a vendor tool.
However, if they do anyway (which I assume is slowly becoming the
dominating case), it'll be much easier to manage compared to gopkg.in
as there will be no need to update import paths between major version
upgrades.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#9 (comment)

[lavalamp]

argh, that was me above. The oncall muxer is spamming me right now, replied to the wrong copy of the message.

[timoreimann]

@lavalamp you mean Kubernetes is consuming client-go itself? Wasn't aware. I know the community / @thockin is making an effort to move to glide, but to my knowledge there are still some blockers along the way.

Anyways, I think gopkg.in still gives users running "modern" vendoring tools an opportunity to reference a single repo and track individual branches while also enabling the more traditional go get style, so personally I'm fine with option 3.

[lavalamp]

Yes. It will. Soon, hopefully.

On Oct 6, 2016 5:56 PM, "Timo Reimann" [email protected] wrote:

@lavalamp https://github.com/lavalamp you mean Kubernetes is consuming
client-go itself? Wasn't aware. I know the community / @thockin
https://github.com/thockin is making an effort to move to glide, but to
my knowledge there are still some blockers along the way.

Anyways, I think gopkg.in still gives users running "modern" vendoring
tools an opportunity to reference a single repo and track individual
branches, so personally I'm fine with that approach.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglqhbb0DUSTBBH2vW47OapWTJhfY8ks5qxZjUgaJpZM4KQgRZ
.

[thockin]

Having the version be in the path is obvious, at least.

On Thu, Oct 6, 2016 at 8:35 PM, Daniel Smith [email protected]
wrote:

Yes. It will. Soon, hopefully.

On Oct 6, 2016 5:56 PM, "Timo Reimann" [email protected] wrote:

@lavalamp https://github.com/lavalamp you mean Kubernetes is consuming
client-go itself? Wasn't aware. I know the community / @thockin
https://github.com/thockin is making an effort to move to glide, but
to
my knowledge there are still some blockers along the way.

Anyways, I think gopkg.in still gives users running "modern" vendoring
tools an opportunity to reference a single repo and track individual
branches, so personally I'm fine with that approach.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglqhbb0DUSTBBH2vW47OapWTJhfY8ks5qxZjUgaJpZM4KQgRZ>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOgQkCk9HRT8vLXfku3m5PLEHZIlks5qxb30gaJpZM4KQgRZ
.

[caesarxuchao]

@timoreimann I added option 5 "abandoning go get" to incorporate your comment.

@lavalamp I don't understand why godep not supporting tracking server in the main repository is a blocker for this idea. It's the same for other 4 options. As long as using godep, we will need to update the godep.json in the main repo to track the latest updates in client-go.

Tracking issue for converting to glide: kubernetes/kubernetes#24202

[deads2k]

How will we indicate the version under active development where we're allowed to making breaking changes? I'm concerned about the controller infrastructure types in particular. Things like workqueues, informers, and listers.

When we were tracking with kubernetes versions it was reasonably obvious, but would we just say that the most recent version can break?

Also, I find myself unhappy with all options. :( @smarterclayton you did our last rebase, any insight?

[lavalamp]

Yes, these options are all bad.

We should track ongoing work in something like 2.0.0-dev.

On Fri, Oct 7, 2016 at 4:48 AM, David Eads [email protected] wrote:

How will we indicate the version under active development where we're
allowed to making breaking changes? I'm concerned about the controller
infrastructure types in particular. Things like workqueues, informers, and
listers.

When we were tracking with kubernetes versions it was reasonably obvious,
but would we just say that the most recent version can break?

Also, I find myself unhappy with all options. :( @smarterclayton
https://github.com/smarterclayton you did our last rebase, any insight?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngluijK7ivLPd-K4Eq6_CH_0Fw0_RKks5qxjGmgaJpZM4KQgRZ
.

[lavalamp]

The downside of doing the logical thing and developing in master and occasionally branching/tagging commits for stable releases, is that anyone doing go get will get some weird state of the repo with no guarantee that we won't break them in an hour.

I'm beginning to think it's the best option despite that, though :(

[caesarxuchao]

cc @mml

[lavalamp]

@mbohlool suggested a slight variation:

• make a dev branch
• use that to track master of the kubernetes repo
• when we cut a client release, in addition to making a release branch, also copy it into master.

So this way go get k8s.io/client-go would get the latest stable instead of the dev branch.

Users who want head (like the main kubernetes repo will, once the client-go repo becomes the canonical place for client development) can implement a process that specifically asks for the dev branch. I think Glide does this for you, and we should be able to hack godep to manage the same thing by setting the revision manually. Or we can build those smarts into our testing tools in the future.

[caesarxuchao]

Even if we use master to track the latest stable version, the go get users will still be broken after we make a major release. Perhaps fail go get users early on is better, rather than giving them a surprise after we make next release.

[lavalamp]

We'll need to make it obvious in the docs what version is currently living in master. Users that do go get -u ... and are surprised can just look at the stable branches and find the one that they were using.

[mbohlool]

My understanding is "go get" is for getting the dependency for the first
time and "godep update" is to update it to the latest release. If that is
the case, I don't think they are broken. godep will keep revision in the
godep.json file, unless you run godep update, it won't change it.
I think this will make it easier for our users by sacrificing a little
comfort in our development process. something like hack/update-client.sh
will get 'dev' branch revision and update Godep.json file with it.

Mehdy Bohlool | Software Engineer | [email protected]

On Tue, Oct 11, 2016 at 4:17 PM, Daniel Smith [email protected]
wrote:

We'll need to make it obvious in the docs what version is currently living
in master. Users that do go get -u ... and are surprised can just look at
the stable branches and find the one that they were using.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABic4Ax2hSud8M6v-pNYPN_CHwAor98Qks5qzBkigaJpZM4KQgRZ
.

[lavalamp]

go get and go get -u are the go language's tool for getting things. The
go tool doesn't track dependency revisions, so it has a problem in that
sometimes go get -u gives you a patch release and sometimes it gives you
a major change.

godep is a separate dependency manager--indeed, it doesn't (shouldn't)
have the problem.

(apologies if I misunderstood what you were saying)

On Tue, Oct 11, 2016 at 4:19 PM, mbohlool [email protected] wrote:

My understanding is "go get" is for getting the dependency for the first
time and "godep update" is to update it to the latest release. If that is
the case, I don't think they are broken. godep will keep revision in the
godep.json file, unless you run godep update, it won't change it.
I think this will make it easier for our users by sacrificing a little
comfort in our development process. something like hack/update-client.sh
will get 'dev' branch revision and update Godep.json file with it.

Mehdy Bohlool | Software Engineer | [email protected] | [phone]

On Tue, Oct 11, 2016 at 4:17 PM, Daniel Smith [email protected]
wrote:

We'll need to make it obvious in the docs what version is currently
living
in master. Users that do go get -u ... and are surprised can just look at
the stable branches and find the one that they were using.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABic4Ax2hSud8M6v-pNYPN_CHwAor98Qks5qzBkigaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglgLjVw5AwmZnmoFICPqyS4zsTtlZks5qzBmNgaJpZM4KQgRZ
.

[thockin]

It's not my repo, so I'll just say this and let you all make the decision.

I think this is strictly worse than just having subdirs and changing import
lines. At least the import lines are dead clear about the situation at any
given point in the repo's history, without cross-referencing godeps. I
think this is too clever and will be very confusing to anyone who uses it
or contributes to it. It doesn't follow any established pattern for Go
that I know.

On Tue, Oct 11, 2016 at 4:25 PM, Daniel Smith [email protected]
wrote:

go get and go get -u are the go language's tool for getting things. The
go tool doesn't track dependency revisions, so it has a problem in that
sometimes go get -u gives you a patch release and sometimes it gives you
a major change.

godep is a separate dependency manager--indeed, it doesn't (shouldn't)
have the problem.

(apologies if I misunderstood what you were saying)

On Tue, Oct 11, 2016 at 4:19 PM, mbohlool [email protected]
wrote:

My understanding is "go get" is for getting the dependency for the first
time and "godep update" is to update it to the latest release. If that is
the case, I don't think they are broken. godep will keep revision in the
godep.json file, unless you run godep update, it won't change it.
I think this will make it easier for our users by sacrificing a little
comfort in our development process. something like hack/update-client.sh
will get 'dev' branch revision and update Godep.json file with it.

Mehdy Bohlool | Software Engineer | [email protected] | [phone]

On Tue, Oct 11, 2016 at 4:17 PM, Daniel Smith [email protected]
wrote:

We'll need to make it obvious in the docs what version is currently
living
in master. Users that do go get -u ... and are surprised can just look
at
the stable branches and find the one that they were using.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253075075
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABic4Ax2hSud8M6v-pNYPN_CHwAor98Qks5qzBkigaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglgLjVw5AwmZnmoFICPqyS4zsTtlZks5qzBmNgaJpZM4KQgRZ>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOnV1fj_RhGHBPVNpwYHrC8UZAgYks5qzBsBgaJpZM4KQgRZ
.

[caesarxuchao]

nit:

I think Glide does this for you

I think Glide cannot track "dev", see https://glide.readthedocs.io/en/latest/versions/.

[lavalamp]

The folders we have now are not standard either, and they prevent us from
doing semver, as the repo will quickly become bloated with patch versions.

On Tue, Oct 11, 2016 at 4:31 PM, Tim Hockin [email protected]
wrote:

It's not my repo, so I'll just say this and let you all make the decision.

I think this is strictly worse than just having subdirs and changing import
lines. At least the import lines are dead clear about the situation at any
given point in the repo's history, without cross-referencing godeps. I
think this is too clever and will be very confusing to anyone who uses it
or contributes to it. It doesn't follow any established pattern for Go
that I know.

On Tue, Oct 11, 2016 at 4:25 PM, Daniel Smith [email protected]

wrote:

go get and go get -u are the go language's tool for getting things.
The
go tool doesn't track dependency revisions, so it has a problem in that
sometimes go get -u gives you a patch release and sometimes it gives
you
a major change.

godep is a separate dependency manager--indeed, it doesn't (shouldn't)
have the problem.

(apologies if I misunderstood what you were saying)

On Tue, Oct 11, 2016 at 4:19 PM, mbohlool [email protected]
wrote:

My understanding is "go get" is for getting the dependency for the
first
time and "godep update" is to update it to the latest release. If that
is
the case, I don't think they are broken. godep will keep revision in
the
godep.json file, unless you run godep update, it won't change it.
I think this will make it easier for our users by sacrificing a little
comfort in our development process. something like
hack/update-client.sh
will get 'dev' branch revision and update Godep.json file with it.

Mehdy Bohlool | Software Engineer | [email protected] | [phone]

On Tue, Oct 11, 2016 at 4:17 PM, Daniel Smith <
[email protected]>
wrote:

We'll need to make it obvious in the docs what version is currently
living
in master. Users that do go get -u ... and are surprised can just
look
at
the stable branches and find the one that they were using.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253075075
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABic4Ax2hSud8M6v-pNYPN_CHwAor98Qks5qzBkigaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253075367
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglgLjVw5AwmZnmoFICPqyS4zsTtlZks5qzBmNgaJpZM4KQgRZ>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVOnV1fj_
RhGHBPVNpwYHrC8UZAgYks5qzBsBgaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglt9iR5cW_kT1bN1m0cUanK8H74Myks5qzBxTgaJpZM4KQgRZ
.

[lavalamp]

It says it can do branches, although the rest of the page doesn't explain
how...

On Tue, Oct 11, 2016 at 4:32 PM, Chao Xu [email protected] wrote:

nit:

I think Glide does this for you

I think Glide cannot track "dev", see https://glide.readthedocs.io/
en/latest/versions/.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglkeuhlH8O3KDQi6e3vGp3pjG69rxks5qzBxygaJpZM4KQgRZ
.

[timoreimann]

@caesarxuchao @lavalamp The top-level doc page on the YML file explains things: You just set the version field for the package in question.

The syntax varies slightly, but it's also possible in govendor and gvt.

[caesarxuchao]

Users that do go get -u ... and are surprised can just look at the stable branches and find the one that they were using.

@lavalamp This convinced me that making the HEAD of master track the latest stable version is better. Do you mind me copying/updating your proposal to the first comment of the issue?

[lavalamp]

Nope, go for it!

On Tue, Oct 11, 2016 at 5:00 PM, Chao Xu [email protected] wrote:

Users that do go get -u ... and are surprised can just look at the stable
branches and find the one that they were using.

@lavalamp https://github.com/lavalamp This convinced me that making the
HEAD of master track the latest stable version is better. Do you mind me
copying/updating your proposal to the first comment of the issue?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngluV8IFsTZgf5ypHoMMPSUWe8vx14ks5qzCMEgaJpZM4KQgRZ
.

[caesarxuchao]

I updated the first comment of the issue.

[thockin]

I wouldn't make a dir for every patch, just for every major version

v1, v2, v3 (since this is the client version, not the kubernetes version)

On Tue, Oct 11, 2016 at 4:36 PM, Daniel Smith [email protected]
wrote:

The folders we have now are not standard either, and they prevent us from
doing semver, as the repo will quickly become bloated with patch versions.

On Tue, Oct 11, 2016 at 4:31 PM, Tim Hockin [email protected]
wrote:

It's not my repo, so I'll just say this and let you all make the
decision.

I think this is strictly worse than just having subdirs and changing
import
lines. At least the import lines are dead clear about the situation at
any
given point in the repo's history, without cross-referencing godeps. I
think this is too clever and will be very confusing to anyone who uses it
or contributes to it. It doesn't follow any established pattern for Go
that I know.

On Tue, Oct 11, 2016 at 4:25 PM, Daniel Smith [email protected]

wrote:

go get and go get -u are the go language's tool for getting things.
The
go tool doesn't track dependency revisions, so it has a problem in
that
sometimes go get -u gives you a patch release and sometimes it gives
you
a major change.

godep is a separate dependency manager--indeed, it doesn't
(shouldn't)
have the problem.

(apologies if I misunderstood what you were saying)

On Tue, Oct 11, 2016 at 4:19 PM, mbohlool [email protected]
wrote:

My understanding is "go get" is for getting the dependency for the
first
time and "godep update" is to update it to the latest release. If
that
is
the case, I don't think they are broken. godep will keep revision in
the
godep.json file, unless you run godep update, it won't change it.
I think this will make it easier for our users by sacrificing a
little
comfort in our development process. something like
hack/update-client.sh
will get 'dev' branch revision and update Godep.json file with it.

Mehdy Bohlool | Software Engineer | [email protected] | +1
650-253-0099

On Tue, Oct 11, 2016 at 4:17 PM, Daniel Smith <
[email protected]>
wrote:

We'll need to make it obvious in the docs what version is currently
living
in master. Users that do go get -u ... and are surprised can just
look
at
the stable branches and find the one that they were using.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253075075
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABic4Ax2hSud8M6v-pNYPN_CHwAor98Qks5qzBkigaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253075367
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglgLjVw5AwmZnmoFICPqyS4zsTtlZks5qzBmNgaJpZM4KQgRZ>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9
issuecomment-253076338
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVOnV1fj_
RhGHBPVNpwYHrC8UZAgYks5qzBsBgaJpZM4KQgRZ>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAnglt9iR5cW_
kT1bN1m0cUanK8H74Myks5qzBxTgaJpZM4KQgRZ>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVMvTbhm0DX18dbjoWXsWmVDoRNFLks5qzB2HgaJpZM4KQgRZ
.

[lavalamp]

I still think it's pretty silly to keep different branches in separate folders instead of separate branches. We're going to have 15 folders in a few years. If we delete old ones, then people have to use a git branch ANYWAY to find their old client.

[smarterclayton]

Why wouldn't old users vendor?

[timoreimann]

If they have to vendor, they can probably track branches anyway. Even more so as today's users turn old and tooling matures.

Personally I very much prefer keeping track of all of my dependencies in a manifest file (vendor.json, glide.yml) as opposed to import statements spread out all across the code base. It's what basically every package manager in any other language does too. The vendor tooling fragmentation in Go is still a nuisance but will hopefully converge towards a few accepted solutions (or at least a set of common formats/standards) over time.

[smarterclayton]

Right - my point is that the current repo is optimized for people who don't want to vendor but don't want to be broken. We're saying we're going to move to a model where you can't avoid being broken without vendoring, which seems worse.

[timoreimann]

@smarterclayton true, users currently need not vendor the library itself. To my understanding, however, they do have to use godep or a vendor tool understanding godep's format as soon as they require one of client-go's dependencies in their own package, as described in the repo README.

Not sure which vendoring need is more likely to come up first to a user: a breaking major version in the new model or a conflicting dependency in the current model. Either way, vendoring seems necessary to avoid breakage.

[caesarxuchao]

We are going to execute the plan as described in the first issue comment.

[nvartolomei]

...or they could use gopkg.in and rewrite our internal import statements.

this does not work afaik, because tags does not contain v prefix, which gopkg.in is looking for.

[timoreimann]

@caesarxuchao I think we should use the v prefix on all tags. It's fairly standard to my knowledge and also what kubernetes/kubernetes does.

Additionally, tools like glide will be able to automatically detect such versioned tags and suggest vendoring them right away.

[thockin]

Tags should be v1.2.3, branches are release-1.2, just like the main repo.
Please.

On Oct 26, 2016 12:20 PM, "Timo Reimann" [email protected] wrote:

@caesarxuchao https://github.com/caesarxuchao I think we should use the
v prefix on all tags. It's fairly standard to my knowledge and also what
kubernetes/kubernetes does.

Additionally, tools like glide will be able to automatically detect such
versioned tags and suggest vendoring them right away.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVFnoXvTFmcLAd6dFw1CF0XSBL33wks5q3ymDgaJpZM4KQgRZ
.

[caesarxuchao]

Ok. Thanks for noting this. I'll add the tags. Is it necessary to create release-1.4/1.5 branches, can I keep them as 1.4 and 1.5? (I'll name future branches release-X.X)

[timoreimann]

The 1.5 was broken up until very recently, and a proper 1.4 isn't around much longer. I'd argue that it's acceptable to rename the branches right away and apologize to the 3 clients we'll break (one of them being me).

Just my 2 cents.

[caesarxuchao]

@timoreimann if I keep naming the branches 1.4 and 1.5, will that break anyone?

[timoreimann]

@caesarxuchao my thinking was that we can reach consistency with very little cost now, as opposed to having to re-educate client users when the next release is cut.

I'm not overly enthusiastic about it though and okay with postponing proper naming to the next release.

[caesarxuchao]

Thanks. I'll try to get @thockin's approval. (I will create the v1.4.0 and v.1.5.0 tags, but starts naming the branches with release- prefix in the next release).

Sorry for all the troubles.

[thockin]

if we want people to find them, it would be nice to be consistent... should
be easy..

On Wed, Oct 26, 2016 at 10:37 AM, Chao Xu [email protected] wrote:

Ok. Thanks for noting this. I'll add the tags. Is it necessary to create
release-1.4/1.5 branches, can I keep them as 1.4 and 1.5? (I'll name future
branches release-X.X)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVNEwZITKcTKDMBkO19zG4tQaDu_Kks5q34_bgaJpZM4KQgRZ
.

[caesarxuchao]

Ok. I'll change the branch name and make tags. (I'm not worried about the difficulty, I'm trying to not break existing users.)

[caesarxuchao]

Done. Sorry for all the troubles.