search

kubernetes-retired / go-open-service-broker-client

A golang client for service brokers implementing the Open Service Broker API
Apache License 2.0
61 stars 51 forks source link

This repo should have a release strategy #92

Closed pmorie closed 6 years ago

pmorie commented 6 years ago

I realized this week that we have never released this repo and are depending on random shas in service-catalog. We should release this repo. There's a question of what the versioning strategy should be.

I'm thinking something like:

I suspect @kibbles-n-bytes @staebler @MHBauer may have some opinions in this area

staebler commented 6 years ago

That versioning strategy seems appropriate to me. I assume that the base version would correspond with the latest version of the OSB API that the client supports.

MHBauer commented 6 years ago

Matching osb release version seems safe and reasonable.

kibbles-n-bytes commented 6 years ago

No complaints here.

pmorie commented 6 years ago

I made an 0.0.1 release to capture what we have before further changes go in, and before we made a final call on the versioning scheme.

One thing that I thought of - going based on the osb release may bite us if we need to make breaking API changes. It's too bad there's no easy way to version the protocol separately from the level of the client in a single version number.

kibbles-n-bytes commented 6 years ago

Talked to @pmorie offline. In order to give ourselves enough flexibility, we probably shouldn't couple our releases here with the OSB versions. The intent of this library is to support all versions of OSB, so there's no real reason for people to have to look back in the past for a specific version; they should just use the latest release. We should instead just make sure to have releases close to when new versions of the spec come out, and these releases can include as a "feature" the added support for that OSB version. This way, if there are necessary breaking changes or critical bug fixes, we don't get ourselves in a pickle. Users can search the release notes if they wish to find an older version that supports their targeted OSB version.

pmorie commented 6 years ago

I'm going to close this for now - we'll stick with normal semver versioning. Next version will be 0.0.2 and continue with 0.0.x until we fix the adherence to the spec schema (which @luksa pointed out as an issue, see #101), after which I think we should go to 0.1.0