Adds version command #198

sloum · 2020-11-01T14:56:39Z

sloum commented

2020-11-01 14:56:39 +00:00

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.

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.

👍 1

sloum commented

2020-11-06 03:38:11 +00:00

@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 or make install run go build or go 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).

@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` or `make install` run `go build` or `go 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).

asdf self-assigned this 2020-11-07 02:35:35 +00:00

asdf commented

2020-11-07 04:17:54 +00:00

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 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?

sloum commented

2020-11-08 18:33:29 +00:00

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 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.

asdf commented

2020-11-09 03:58:53 +00:00

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 error fatal: no tag exactly matches 'commitID'. git describe --tags shows 2.3.1 for the main branch, and 2.2.1-63-g97b74ea for develop.

[I think I first added it to `gfu`](https://tildegit.org/sloum/gfu/pulls/4), 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 error `fatal: no tag exactly matches 'commitID'`. `git describe --tags` shows `2.3.1` for the main branch, and `2.2.1-63-g97b74ea` for develop.

sloum commented

2020-11-12 23:57:44 +00:00

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.

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.

👍 1

sloum referenced this issue from a commit

2020-11-20 04:02:20 +00:00

Merge pull request 'Adds version command' (#198) from version-command into release2.3.3 Reviewed-on: https://tildegit.org/sloum/bombadillo/pulls/198

sloum merged commit b8ae9d659c into release2.3.3

2020-11-20 04:02:21 +00:00

sloum deleted branch version-command

2020-11-20 04:02:32 +00:00

Sign in to join this conversation.

No reviewers