Adds version command #198
No reviewers
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#198
Loading…
Reference in New Issue
No description provided.
Delete Branch "version-command"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds a version command to get the version from within bombadillo.
I will add this to the manpage too, but dont ahve time right now, so do not merge in yet.
@asdf I made a minor change to this PR:
If there is no version data in the version variable (ie. it is an empty string) and the user runs the version command it will print:
Bombadillo version: Improperly copmiled. No Version information
rather than, for example:Bombadillo version: 2.3.3
.To get this to happen, for testing purposes, rather than running
make
ormake install
rungo build
orgo install
. In either of those cases there is nothing to inject the version number into the build so it just ends up being blank. Since this is against our build instructions I felt like this would give us a clear way to know when someone did not follow those instructions for their build and thus maybe be able to source other issues they may be having.What do you think? I could change the wording if you can think of something better (you have generally been pretty good with wording for stuff like this).
I was thinking about this too after your comment on the other issue. Should we simplify and just store the version in
main.go
?The original idea was to automatically get version info from git tags, and fallback to the version file if any issues. It doesn't seem like we are getting much out of that implementation, as we still write the version in git tags and a file. Plus it not working for go builds sucks a bit.
Writing it to main.go would ensure version info is available even if you don't use the makefile. It isn't that much different, but requires less implementation.
Not sure if I'm missing something - are there any other requirements that would not be met? For example, do we need to differentiate between go builds and make builds? Do we need git branch or commit info?
I think you are right that we could probably move away from the VERSION file. To we still want to have the make builds update the version value in the code? It could default to what we put in and if there is a tag and it is built with make it will use that instead, giving extended information?
I can make the changes and commit them to this branch. Do you think that is the good way to go? As I recall either you or jboverf were the one to set up the VERSION file and add that bit to the makefile, so I would definitely love advice on it.
I think I first added it to
gfu
, with the original idea being to set the version info in git and have it automatically come through to the build process.VERSION
was added as a backup for situations where git wasn't present, or for some other issue with a git tag. I think the idea was to expand further with this, using a script to update the version file and tags in one go.What you describe sounds good. If you need some help I can take this on.
I am not sure the current command to get the tag is working though, and suspect it may be always failing to work. Running the command
git describe --exact-match
shows the errorfatal: no tag exactly matches 'commitID'
.git describe --tags
shows2.3.1
for the main branch, and2.2.1-63-g97b74ea
for develop.Yeah, the tag thigns was a cool idea I think. But since we are already creating a manual backup it may be better to just store version information in the version variable and ditch both the makefile versioning as well as the version file itself.
I will do that tonight and merge this in. I think that should put us at a release point. Which will be nice. I think I will take this one all the way to master so that package maintainers can easily ship versions with a lot of the gemini bugs fixed.