Python: Release 1.0 stable

[mbohlool]

I think the client is stable enough for first release. I've release Beta 2 Beta 3. Please give it a try and report back any problems. If there is no serious issues, I will release 1.0 in a week (target 2/28/2017).

[mrmcmuffinz]

Actually to be clear it is 1.0.0b3 there were some missing requirements in setup.py which broke the build and were fixed in 1.0.0b3

[dims]

agree 1.0.0b3 should be good (https://github.com/kubernetes-incubator/client-python/compare/v1.0.0b2...v1.0.0b3)

[mbohlool]

Updated first comment to to beta 3. I wrote it before we found the bug in beta 2 setup.

[mrmcmuffinz]

Few questions:

1. How do you want us to report issues, open up the issue right away or report it first elsewhere and then if it is valid open it up?
2. Are we going to see up to date examples with the better approach of setting up/loading the kubernetes config?
3. I actually do have an situation where I'm not sure if it counts as an issue but I my problem is as such. When accessing the namespace hardware information my expectation is that I should be able to access the dictionary keys as ordinary members but it does not seem that way for the below two cases:

response = kubernetes_client.read_namespaced_pod_status(pod_name, kubernetes_namespace, pretty=pretty)
response.spec.containers[0].resources.limits["cpu"]
response.spec.containers[0].resources.limits["memory"] 

Am I right to have the prior expectation or is this working as intended?

[mbohlool]

1. I think like the rest of kubernetes, slack channel of SIG is the best starting point, then maybe creating issues.
2. We have some examples on that, what do you have in mind? PR is welcome :)
3. That should work if cpu or memory is in that map (that is not there all the time according to my test). Check if "cpu" in ... first.

[dims]

In addition to what @mbohlool said, would love to see code snippets in the issues, so we can then turn that into unit or e2e tests quickly.

Thanks,
dims

[mrmcmuffinz]

I'm on the kubernetes.slack.com, is there a dedicated channel for talking about this codebase?

[mrmcmuffinz]

Follow up question, what will the protocol be now for new releases, lets say we find a bug and a fix goes in, when do we bump it?

[mbohlool]

Depends on the problem and how severe it is. We can decide on a case by case basis for now I guess.

[mbohlool]

Look like I need to call the stable release 1.0.1 to make sure it is bigger than 1.0.0b*.

[mrmcmuffinz]

Can we go with v1.1.0 instead? My reasoning is that if we go off of http://semver.org/ we are releasing a minor change and so the minor should be bumped once we deem it fit for public consumption. If we see that there are any issues then we deliver a fix and that would be considered a patch such as the recent delivery we did on exec and extra data from the channel.

Sent from my iPhone

On Feb 26, 2017, at 4:18 AM, Mehdy Bohlool [e-mail] wrote:

Look like I need to call the stable release 1.0.1 to make sure it is bigger than 1.0.0b*.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[dims]

@mbohlool 1.0.0 is higher than 1.0.0b in all the typical tools like pip etc. So we should be good. if we do see a problem, then we can release a 1.0.1

[mrmcmuffinz]

Hi @mbohlool & @dims, with which release version will we be going with?

[mbohlool]

@dims Sure, I was wondering if we can just skip any problem by using 1.0.1, but if packaging tools understand that 1.0.0 > 1.0.0b then we should be good.

@mrmcmuffinz 1.0.0 probably. I will try to test it before releasing.

[WilliamDenniss]

@mrmcmuffinz It's valid semver to have a beta suffix which is deemed less than the final release with the unsuffixed number http://semver.org/#spec-item-11

[mrmcmuffinz]

@mbohlool ok, though how does that fit with what is in in CHANGELOG.md as I see v1.0.1?

@WilliamDenniss ok, I don't disagree with that statement nor do I see where I made the opposite claim. Could you please clarify where the misunderstanding is?

[mbohlool]

@mrmcmuffinz I will change that.

[mbohlool]

The release is live: https://github.com/kubernetes-incubator/client-python/releases/tag/v1.0.0