Please make a release

[gijzelaerr]

for example 0.1

Please don't name it 0.1alpha, rather use semantic versioning https://semver.org/

[david-macmahon]

I think releases would be good, but I'm not sure about semantic versioning for this project (yet). Semantic versioning mandates various levels of compatibility between various levels of releases. I think, sadly, that our software development methodology as a group is not rigorous enough to make those compatibility guarantees from release to release. I would be more in favor of a date-based release (e.g. 20180401) as a compromise between no releases and semantics versioning.

[gijzelaerr]

I think you are assuming too much of sentimental value to the use of a version number. In the end, people don't really care that much. Semantic version numbers are easier to pronounce and to read compared to dates. If the software is alpha alpha for now and the foreseeable future I would recommend to starting numbering at 0.0.1 and move up from there. I don't see how this low number semantic versioning naming scheme would give a false impression of stability.

That said, having a release is better than no release, so if you guys prefer to use a date-based release anyway I'm not against.

[gijzelaerr]

A good hybrid would be to start with 0.0.20180316, since it would be compatible with the semantic versioning (0.1 would supersede 0.0.20180316).

[david-macmahon]

The summary section on https://sermver.org says:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

It's a great model, but I don't think we have enough testing infrastructure or code review time to go through and classify whether each change is a PATCH, MINOR, or MAJOR change. Without that, I think mimicking a semantic version numbering scheme is misleading to those who expect the above semantics and confusing/overly complicated for those that don't know about semantic versioning.

[david-macmahon]

I think using 0.0.20180316 is fitting a square peg in a round hole. It implies that all 0.0.x versions will be date based and then some day we'll reach semantic versioning Nirvana and release properly semanticized version 0.1.0 and from then on follow semantic versioning. I wish we could just start with SV to begin with, but I don't think that's realistic given our constraints.

[gijzelaerr]

Ok so what do we do? :) My worry is that when we make and distribute the packages they are updated and upgraded properly when new versions are made. When semantic versioning (or the data based hybrid) is used, the upgrade path works properly. But if in the future you switch from a pure date as a version to a semantic version at some point this will break: 0.1 < 20180316, so the package is not updated. This is why I recommend prepending it with 0.0.. Also, I think it would be good to have a consistent version scheme between all unversioned packages floating around.