search

alavrik / piqi-erlang

Protocol Buffers, JSON, XML data serialization system for Erlang
http://piqi.org/doc/erlang
Apache License 2.0
68 stars 28 forks source link

Don't use {vsn, git} #12

Closed AeroNotix closed 10 years ago

AeroNotix commented 10 years ago

Please properly tag your commits with a known commit hash rather than relying on the git tag, it breaks other tools and tags like v0.7.0 are not valid versions.

alavrik commented 10 years ago

Hmm. Not sure what you mean by not relying on git tags for tagging commits. The v0.7.0 release was tagged correctly using an annotated git tag. It is the standard git tagging method for releases. Can you clarify what's wrong with it?

As for the v0.7.0 version, it is surely an acceptable and valid value for the vsn field in the .app file. In fact, all latest piqi-erlang releases were tagged this way. Prefixing version numbers with a v in tags is, again, a pretty standard practice. While I agree that it would be nicer to have a version without a v as the Erlang application version, not sure what would be the best way to achieve this with rebar. One way is to replace {vsn, git} with something lke {vsn, {cmd, "git describe --always --tags | sed -e 's/^v//'"}} but there is a chance this can break other build tools.

Besides, it looks like the original bug in relx that caused the problem has been fixed. So, should we bother trying to strip the v prefix here?

AeroNotix commented 10 years ago

You do know that as soon as you commit again the v0.7.0 tag won't be used as the version number for piqi? It takes the latest sha1 when not using a tag. These are not orderable in any relatively easy way.

Using a prefix v also means that the common libraries for parsing this out strip it (namely erlware commons). I understand the want to include v before the number as it's more visually apparent but it does raise a few questions as to how useful it is when it so easily breaks third party tools.

Closing for now as it's currently irrelevant to me but it's something to think about.

alavrik commented 10 years ago

You do know that as soon as you commit again the v0.7.0 tag won't be used as the version number for piqi? It takes the latest sha1 when not using a tag. These are not orderable in any relatively easy way.

This is not true. Here's what the version would look like if added another commit:

$ git describe --always --tags
v0.7.0-1-g91ad378
AeroNotix commented 10 years ago

Then it's strange why relx only broke when you added the new tag.

alavrik commented 10 years ago

There were no previous tags in the "master" branch. For this reason, the pre-release version looked like a plain sha1, that is it didn't start with a v. So, there was nothing for relx to strip and cause the discrepancy.

AeroNotix commented 10 years ago

On 29/10/13 10:28, Anton Lavrik wrote:

There were no previous tags in the "master" branch. For this reason, the pre-release version looked like a plain sha1, that is it didn't start with a |v|. So, there was nothing for relx to strip and cause the discrepancy.

— Reply to this email directly or view it on GitHub https://github.com/alavrik/piqi-erlang/issues/12#issuecomment-27288204.

Gotcha, makes sense now.