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
103 stars 58 forks source link

Tagging a "real" release #18

Closed l3u closed 6 years ago

l3u commented 6 years ago

Apparently, the rework is okay, ahd some other stuff has been fixed as well?

What about tagging and creating a "real" release? E. g. with version number 0.99? I was working on a Gentoo ebuild for vcontrold, and it would of course be much nicer to reference a real release than some git ID.

What do you think?

speters commented 6 years ago

IMO reserve the bump to a new minor version when the xml configs are sorted out, and advance the patch level instead. 0.99 looks too close to 1.00 ...

l3u commented 6 years ago

Would be just as fine.

hmueller01 commented 6 years ago

It's good to tag this state. We made no functional enhancements only bug fixes and code style fixing, so I would prefer a minor release too.

speters commented 6 years ago

I finally managed to set up Travis CI with cross-compilation for armhf and a very basic deployment to GitHub releases.

Tagged v0.98.4

l3u commented 6 years ago

You forgot to add a version.h file with the correct version hard-coded – the tarball won't compile due to this file not being there (and cmake unable to generate it because it's not a git clone) …

l3u commented 6 years ago

cmake should generate a dummy version.h in this case though …

l3u commented 6 years ago

At least, not building a version.h file in each case should be fixed with commit 9f08fb2. We need another (bugfix) release though – the released tarball will fail compiling as said.

speters commented 6 years ago

Thx for pointing this out. I didn't have those users in mind who prefer a tarball over a git repo clone. I re-released v0.98.4 including commit 9f08fb2ea14d6e72a4c323f10180a667c0bcaeb0, as the sources and the resulting binaries remained unchanged and I doubt that any signed package were released in the meantime. Will not happen again (fingers crossed).

l3u commented 6 years ago

Thanks, for re-releasing the tarball! But the version is still set to "unknown" through the fallback. I thought it was possible to add manually created files to releases hosted on github? If not, we should add a version.h file with the last release version (which will be overwritten by the cmake function), or we always have "unknown" as the version when using tarballs. Distributors (at least Gentoo ;-) don't like git clones, they want tarballs to be put on mirrors.

speters commented 6 years ago

Ah, ok. I got you now. It is possible to add files to GitHub releases, but the zipped/tarred source archives provided by GitHub can not be overridden or deleted.

What about deriving the version from the path name of the source directory? In GitHubs source archives, the sources are located in a reponame-tagnamewithoutv directory (e.g. in vcontrold-0.98.4 . This seems consistent with the Gentoo and the Debian naming scheme.

l3u commented 6 years ago

Isn't it possible to do a "real" release including the version.h file and provide it? And leave the Github generated ones out? I mean, your proposal would most probably work, but we're solving a problem that only exists because Github auto-generates tarballs, and we would not have this problem if a real release was hosted somewhere else …

speters commented 6 years ago

The releases deployed via TravisCI now include