Commit graph

3 commits

Author SHA1 Message Date
Matt Ellis 2b3c7f61c5 Rework get-version scripts
Under our old versioning system, when we started a new point release,
we'd tag the HEAD commit of master with a tag like `v0.16.6-dev` and
our scripts would use this to generate a new version number. This
required a great deal of gymnastics when producing a release and
caused us to litter these -dev tags everywhere.

To improve this, we change version number generation to the following
strategy:

1. If the commit we are building has a tag applied to it, use that tag
as the version (appending the dirty bit metadata to the version, if
needed).

2. If the commit we are bulding does not have a tag applied to it,
take the version from the next reachable tag, increment the patch
version and then append the `-dev` pre-release tag. As part of this,
we also make a slight tweek to our semver generation such that instead
of `-dev<TIMESTAMP>` we use `-dev.<TIMESTAMP>` which is more in line
with what semver recommends.
2018-11-16 20:11:04 -08:00
Matt Ellis 7b27f00602 Fix python package versions
Our logic for converting npm style versions to PEP-440 style versions
was not correct in some cases. This change fixes this.

As part of this change we no longer produce a NPM version that would
be just X.Y.Z-dev, instead for development versions we always include
both the timestamp of the commit and the commit hash.

Instead of trying to use a bunch of sed logic to do our conversions,
we now have a small go program that uses a newly added library in
pkg/util. A side effect of this is that we can more easily write tests
to ensure the conversion works as expected.

Fixes #1243
2018-05-07 12:38:08 -07:00
Matt Ellis 5c4a31f692 Adopt new version strategy
Our previous strategy of just using `git describe --tags --dirty` to
compute a version caused issues. The major one was that since version
sort lexigrapically, git's strategy of having a commit count without
leading zeros lead to cases where 0.11.0-dev-9 was "newer than"
0.11.0-dev-10 which is not what you want at all.

With this change, we compute a version by first seeing if the commit
is tagged, and if so, we use that tag. Otherwise, we take the closest
tag and to it append the unix timestamp of the commit and then append
a git hash.

Because we use the commit timestamp, things will sort correctly again.

Part of pulumi/home#174
2018-03-15 18:06:04 -07:00