Added release notes

[TomAugspurger]

I chose to name make this version 0.10.0. Dunno if we want to move to date-based versioning like the other Dask projects.

[consideRatio]

Oh can we make it 1.0.0 instead? It helps communicate changes with semver. We had a alot of jupyterhub projects become 1.0.0 for this reason and it has been great - it becomes clear how to bump versions etc instead of unclear, for maintainers and users.

For something like this, i suggest not using calver, but i dont know.

[jcrist]

I'd actually rather use calver to match the other dask release conventions. dask-gateway isn't really released on a clear schedule, and the default images are just a snapshot of whatever dask/distributed/etc... releases were latest at that time. Calver seems like the right fit to me.

[consideRatio]

Calver / semver both seem like great improvements from using 0.x.y as we can communicate so little with 0.x.y.

A big +1 for just going with one of calver / semver right now rather than sticking with 0.x.y.

Note that the helm chart version cant have leading zeroes like 20.04 in ubuntu, because it must be semver2 compliant in format according to helm3

[martindurant]

@TomAugspurger , dd you want to update this to use calver?

[TomAugspurger]

Fine by me. Is there a target date set, or do you want to set the date and version at https://github.com/dask/dask-gateway/pull/467/files#diff-ef86237172bb2f91c585e845b38d6fb28bb6ac128ff8efa541cdd86f81751bf2R4 and merge this in just prior to releasing?

[martindurant]

It would be really nice to do it this month. There would be no need in the changelog, then, to specify the exact release date if it's already in the version.

[consideRatio]

Thanks for driving this onwards @martindurant and @TomAugspurger! What CalVer format is proposed?

Beware of helm being strict about SemVer2 compliant versions!

CalVer can be used in many formats, and a subset of these are SemVer2 compliant in its format, while not all of them. helm the CLI enforces that Helm charts use versions that are SemVer2 compliant - so if CalVer is used, it must have a format that is SemVer2 formatting compliant.

In short, the CalVer format would need three numbers (1.2.3), and the numbers must not have leading zeroes - then we won't run into issues with the Helm chart's stricted version requirements.

[martindurant]

In dask we are using YYYY.MM.X where X is 0, 1, 2 for as many releases as happen in a month. We will always be .0 :)

[consideRatio]

@martindurant with YYYY.MM.X, we would have 2022.02.0 today if we cut a release - right? That would not be a valid SemVer2 version =/ The leading zero in the month makes it fail... Fine with PyPI - but not with Helm charts (as enforced by the helm CLI).

[martindurant]

That's true, but pip tools strip the 0 anyway. If helm has a problem with it, .2. is fine too. This is for user interpretation mostly, and will still work with split-and-int either way.

[consideRatio]

@martindurant okay so in this project - do we consistently go for YYYY.M.X format for the projects artifacts? We have the following artifacts influenced I think.

1. Notes in changelog etc
2. Git tags in this repo
3. conda-forge/PyPI packages
4. Docker images
5. Helm charts (must have YYYY.M.X rather than YYYY.MM.X)

[martindurant]

Yes, that's OK with me. Perhaps let the other people on this thread have a say until end of today.

[martindurant]

I suppose I forgot - still good to merge here?

[consideRatio]

Merge and iterate sounds great to me.

I sidetracked a bit on a versioning discussion but it is my understanding that we are to go for a YYYY.M.X release for all of our release artifacts, which would be the Python packages, Helm chart and associated docker images.

[martindurant]

+1 , we'll update the final version string when we have release credentials.