Binary versions with build metadata #242
Conversation
erak
force-pushed
the
erak/bin-version
branch
from
5d68666 to
7285b4e
Compare
|
How about removing the 'vergen' package when things are finalized? It works, but introducing a new dependency comes at a cost. |
|
Indeed, |
|
👍 I can help out with this once we're settled on the requirements |
|
Here's the patch for bumping the version to 0.7.0-dev |
Signed-off-by: Erik Kundt <[email protected]>
Signed-off-by: Erik Kundt <[email protected]>
erak
force-pushed
the
erak/bin-version
branch
from
7285b4e to
10dfad2
Compare
|
@slack-coder I picked your commit, thanks! @cloudhead Together with that and the snippet you posted, the version is now being reported as e.g. |
| use std::process::Command; | ||
|
|
||
| fn main() { | ||
| let hash = Command::new("git") |
There was a problem hiding this comment.
fwiw - I have a feeling this is / maybe going to be flaky and will / may sometimes break things and can potentially cause friction there and there. it would be better to have it in automated builds that have the appropriate handling for it across all the different builds. build.rs is useful e.g. with protoc for code generation but not necessarily for managing build metadata.
I mean there is a risk and generally I try to avoid build.rs as much as I possible can 🤷♀️
There was a problem hiding this comment.
Could you maybe elaborate on what you expect to be flaky? I think I'm just to new to build scripts and might be missing something here. What would be a more appropriate solution to this problem other then build scripts?
Besides automated builds, I think it should be possible to have a proper version output for local builds.
|
fwiw - It's probably worthwhile to start using CHANGELOG.md using "standard" keepchangelog https://keepachangelog.com/en/1.0.0/ e.g. see example use: https://github.com/khonsulabs/bonsaidb/blob/main/CHANGELOG.md And align on https://semver.org/spec/v2.0.0.html use. As to the -dev etc. suffix(es) it's best generated in -nightly, -pr etc. automated "tagged" release-builds rather than off manifest / build.rs which should reflect the "base version" at master / main or the expected future release. e.g. look nightly release builder: https://github.com/pinkforest/test-auditable-releases It makes nightly releases based on matrix using git tags pushing to timestmaped nightly ver. I have a separate repo for radicle-nightly but I'm tuning some of the target triplets that I need for testing: https://github.com/pinkforest/rad-release/releases/tag/radicle-cli%40nightly-20220908-0511 When the CHANGELOG.md is using standardised form typical release tooling has pattern to extract it out automatically. |
Oh, yes. We should add a changelog. I've filed an issue tracking this: #249
I agree with the base version here, but was under the impression that people were leaning towards this solution.
Cool, that's very valuable! I'm in favor of providing nightly builds. But as mentioned above, it should be possible to distinguish local builds as well. What would be your proposal here? I think overall, I'd be in favor of finding a simple solution that works for now and can be changed later. I fear that starting the conversation around nightly builds will block this from being done. And we should also keep in mind, that with the project slowly moving away from Github, we'll lose CI for now. |
|
@pinkforest check the issue for the PR, it may be a good place to follow up so as not to fragment the discussion. |
I like it :) this will help a lot with bug reports |
Closes #239.