search

openv / vcontrold

:fire: vcontrold Daemon for control and logging of Viessmann® type heating devices
https://github.com/openv/openv/wiki
GNU General Public License v3.0
102 stars 57 forks source link

Added a nicer automatic versionning mechanism. #8

Closed l3u closed 6 years ago

l3u commented 6 years ago

This is how we do it with KPhotoAlbum. I also use this very mechanism for other projects. Works like a charm :-)

It creates a version.h file from the git description. If we want to do a release, we simply leave out version.h.in and add a version.h with the correct version (via a release script, by hand, or whatever). The cmake module knows if we're on git or on a tarball.

Commit 7a608e8e1583000135e2f14d6627fbaeb0f6cd90 is the latest state of the sf.net code. You added a "v0.99.3" tag for this one, but it's a leightweight tag (and it wasn't possible to change it to an annotated one). We need annotated tags for this to work, so I added one ("v0.99.4") for this commit (I think the most important part is to be sure that we don't get confused with the legacy code, and this is the case however).

If you like it, merge it. As said: it's really fine and has been working for quite a long time in other projects, and no code has to be changed for this to work :-)

Ps: Why did you create some tag for the cmake transition (0.99.10)? I'd only tag releases with version numbers. And always annotated. It's fine to have other (unannotated) tags around (and the module will distinguish here, as it only uses annotated ones for the version generation), but I think it's confusing if we have release-like (version number) tags that are no actual releases.

speters commented 6 years ago

Thanks for this, looks far better than my approach.

Also, I didn't take into account the differences between lighweight and annotated tags. Thx for pointing these out. The overjealously chosen tags are now removed. I added a back-dated annotated "v0.98.2-107+IPv6" tag for the SF.net import with "107" denoting the last SVN revision. This is "compatible" to the proposed semantic versioning, but resembles the version number originally chosen by the authors.

I'm still a bit unsure, on how wise it is not to supply a version.h, as GitHub offers automatically generated ZIP-archive and tarball downloads of the sources on both the main page, and the "Releases". So there might be quite a few people who will download these.

l3u commented 6 years ago

You're right, this actually breaks the mechanism.

Is it possible to host "real" releases here? With static, prepared (probably also signed and/or checksummed) tarballs? Then, it would be no problem to leave out the version.h.in and provide a version.h containing the real version number (that's what we/I do with other projects using this versionning approach).

For the zip downloads to work, I think we/I have to add some fallback mechanism to the version generation. If version.h isn't there, and we aren't on git, we simply generate one with "unknown" as the version string or so.

Let me check this out.

l3u commented 6 years ago

According to https://help.github.com/articles/creating-releases/ (7), we should be able to include a pre-generated version.h file into a release.

speters commented 6 years ago

Please take a look at my proposal:

l3u commented 6 years ago

To require cmake 3.2 is of course meaningful. I'm also fine with using --dirty :-)

The placement of version.h to the base dir instead of src/ was intended, as this one is a generated file not to be confused with the "real" code. Most probably a matter of taste, but I would leave it in the base dir.

Do it how you like it. if you also want to separate it from the non-generated sources, move it back. If not, just leave it as-is ;-)