search

pangeo-data / helm-chart

Pangeo helm charts
https://pangeo-data.github.io/helm-chart/
21 stars 26 forks source link

consistent versioning of helm chart #31

Closed rabernat closed 5 years ago

rabernat commented 6 years ago

Right now we are at v0.1.1 and have been for a while. Yet we continue to update the helm chart using date and / or hash-based suffixes...

What is the accepted best practice for helm chart versioning? How do we determine when to increment the version number?

jacobtomlinson commented 6 years ago

My preference is to embrace SemVer fully.

I feel like iterating using hashes is useful for testing experimental versions of the chart, but when we are happy it is stable we should increment the version by doing a release.

mrocklin commented 6 years ago

I've found that CalVer https://calver.org/ is useful for projects that have a large API surface area, where determining minor vs major version changes is sometimes not entirely clear.

On Mon, May 21, 2018 at 6:10 AM, Jacob Tomlinson notifications@github.com wrote:

My preference is to embrace SemVer https://semver.org/ fully.

I feel like iterating using hashes is useful for testing experimental versions of the chart, but when we are happy it is stable we should increment the version by doing a release.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pangeo-data/helm-chart/issues/31#issuecomment-390612362, or mute the thread https://github.com/notifications/unsubscribe-auth/AASszDae1rvlL3bm2LeQE7Msx42BQhgrks5t0pKNgaJpZM4UGM8D .

jacobtomlinson commented 6 years ago

Interesting! That does sound useful for this project particularly as it is more of a stack or bundle which is continuously evolving.

guillaumeeb commented 5 years ago

Let's go for CalVer, then! I propose YY.0M.0D or YY.MM.DD.

For the time to do a release, opening an issue when someone believe it should be done seems good to me for a small project. I guess we should do a catch-up release soon if we consider the project is still useful (see https://github.com/pangeo-data/pangeo/issues/511).

jhamman commented 5 years ago

@guillaumeeb - interested in taking a swing at this?

guillaumeeb commented 5 years ago

Sure, I can look at this next week probably. Are we waiting on some opened issue or PR before officialy releasing?

I guess the process should not be to complicated, I will look at that.

guillaumeeb commented 5 years ago

Okay, I think I'd better use the help of @jacobtomlinson here.

What are the steps to do an official release of this chart? Something like:

  1. Open a PR, or directly change the version in https://github.com/pangeo-data/helm-chart/blob/master/pangeo/Chart.yaml
  2. put a tag in git : git tag -a x.x.x -m 'Version x.x.x'
  3. Call chartpress manually using --tag option? Any idea here?

Currently, we only have Development releases in https://pangeo-data.github.io/helm-chart/, so I guess they have all been issued with default chartpress command from travis CI.

Additionnal questions:

guillaumeeb commented 5 years ago

So I found some information here: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/master/CONTRIBUTING.md#releasing-a-new-version-of-the-helm-chart.

We don't need all this, but looking at the key part with chartpress, it seems I don't need to manually change version, so #84 is probably wrong.

jacobtomlinson commented 5 years ago

Historically releases were done by creating a tag on GitHub. Travis should do the rest.

However I think we should switch to CalVer and let Travis do all the releases in the same way.

The other option would be to keep in lock step with z2jh and do a mix of SemVer and CalVer to make it clear which version of z2jh we are using. (e.g 0.8.0.190211)

guillaumeeb commented 5 years ago

Historically releases were done by creating a tag on GitHub. Travis should do the rest.

But there are no Stable release currently. Only development one with a commit hash. I think we should have some stable releases.

The other option would be to keep in lock step with z2jh and do a mix of SemVer and CalVer to make it clear which version of z2jh we are using. (e.g 0.8.0.190211)

That looks frightening 😁. We probably need to document stable release though, and indicate here which z2jh version we are using.

jacobtomlinson commented 5 years ago

But there are no Stable release currently.

I guess this is the benefit of using >1.0 in SemVer. CalVer is fundamentally for unstable projects.

jacobtomlinson commented 5 years ago

We should progress this as @jhamman has tagged 0.2.0 in the GitHub releases but it's still showing as pangeo-v0.1.1-c04d8fa in the chart repo and #84 is still hanging around.

Let's try and reach a consensus.

guillaumeeb commented 5 years ago

Yeah sorry, I'm lagging here...

What I would like is something like having YY.MM.dd-commit_hash upon PR (and which is listed as developement releases), and YY.MM.dd upon git tag (listed as stable releases). So I think this means:

I will try to test this tomorrow.

jacobtomlinson commented 5 years ago

Sounds good to me! (Although I would still argue the point that there is no such thing as a stable release in CalVar ;), but this seems a good compromise)

guillaumeeb commented 5 years ago

I think #85 works fine!

I've tested with PR merge and with tag.

One thing to keep in mind though, I don't use ${TRAVIS_TAG} upon tags. I always force the chartpress tag to YY.MM.dd (tested it by tagging to 0.2.1). So we should for consistency use calver syntax as git tags to I believe.