[meta] v0.2 release checklist

[formatc1702]

Tasks to do before v0.2 release.

• Change __version__ to 0.2
• Add release date to CHANGELOG.md
• Rebuild examples
• Merge dev into master
• Add v0.2 tag to the merge commit and push tag
• Publish to PyPI
• Change __version__ to 0.3-dev in dev branch

@ contributors: [CC'ing @kvid directly for his deep involvement]
If there are any other tasks that you feel should be completed before the v0.2 release, please submit them as issues with the [pre-release] prefix and I'll add them to the v0.2 milestone comment here and I'll add them to the checklist so nothing gets lost.

However, I'd like to escape the trap of diminishing returns, so these issues should not include any new features, or even improvements, unless they fix a critical bug/mistake.

Once all other pending issues/PRs are closed, I will perform the actual release; hopefully I can achieve this before the end of the week.

[kvid]

Your versioning practice seems to be according to accepted recommendations, PEP 386 and PEP 396.

However, is it usual practice to bump the version number from 0.2 to 0.3.dev? Isn't 0.3.dev regarded as a later version than 0.3? And what if you decide to release a 0.2.2 version for a minor but critical bugfix before 0.3? I would have expected a minor bump only from a release to the dev branch immediately after, e.g. 0.2.1a or something of similar minor bump amount, but I'm not an expert on this.

[formatc1702]

Semantic versioning says:

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

Note that they recommend increasing the minor version, not the patch version. Since anything before 1.0.0 is considered "initial development" and anything may change at any time, there is no use in maintaining detailed records using the patch version. Since patch will therefore always be at 0, the conscious decision was made not to include it.
However, as more people use the project, the probability of needing to release quick bugfixes rises, so it is worth considering keeping the patch version in there "just in case".

This conflict raises the question, when would the project be considered to be 1.0.0-ready, with people expecting bugfixes between version releases? But that's an issue I'd like to discuss separately.

Isn't 0.3.dev regarded as a later version than 0.3?

Similar to alpha, beta and rc versions, adding dev to a version places it before the version without the suffix. Semver says:

When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:

Example: 1.0.0-alpha < 1.0.0.

I have seen both . and - as the delimiter before the suffix, but - seems to be the more common variant.

[kvid]

Isn't 0.3.dev regarded as a later version than 0.3?

Similar to alpha, beta and rc versions, adding dev to a version places it before the version without the suffix. Semver says:

When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
Example: 1.0.0-alpha < 1.0.0.

I have seen both . and - as the delimiter before the suffix, but - seems to be the more common variant.

You are right. Personally, I think it's easier to accept 0.3-dev < 0.3 with a dash instead of a dot, but others might disagree.

It seems the conflict issue in #172 never made it into v0.2 after all - I hope that's your intention and not just forgotten.

[formatc1702]

It seems the conflict issue in #172 never made it into v0.2 after all - I hope that's your intention and not just forgotten.

I can see this issue really has you worried ;)

The way I see it, the current setup works, and will not cause any problems with the release.
I am leaving the issue open to hopefully get some clarity in the future, but I will not let this delay the release any further.
I was tempted to at least remove the lone . but I'd rather wait for definitive confirmation on that too.
The duplicate requirements list is, especially with a total of only three packages, mainly an issue of purism, not of functionality or maintainability at this point.

So, not forgotten, but deliberately left open to avoid multiple steps of fixing without a defined goal / generally agreed best practice solution.

---

Personally, I think it's easier to accept 0.3-dev < 0.3 with a dash instead of a dot, but others might disagree.

I've changed it to - because I feel the same after re-reading the SemVer docs.

[formatc1702]

v0.2 has been released! Thanks everybody for your contributions.

I will start going through the PRs as discussed in #101 in the following days.