Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An option or subcommand that shows only the version number #249

Open
nacho4d opened this issue Jan 5, 2022 · 4 comments
Open

An option or subcommand that shows only the version number #249

nacho4d opened this issue Jan 5, 2022 · 4 comments

Comments

@nacho4d
Copy link
Member

nacho4d commented Jan 5, 2022

I think we need an option/subcommand to show only the version number and exit with 0 status.
This command will become handy when submitting bugs. Users ideally should mention the version they are using and having problems with.

xchtmlreport -v is already taken so xchtmlreport --version ?

@tylervick
Copy link
Member

+1 to this - I also think we need a way to unify versioning between git tags and the hardcoded string in the swift file.

I'm not really sure of a good way to do this - SPM/mint/etc. uses tags, whereas the --version command would need some way of updating the string (maybe via resources/some other CD job)

Also, this is a good enough reason to replace -v with something like --debug or --log-level.

@nacho4d
Copy link
Member Author

nacho4d commented Jan 6, 2022

Yeah! I agree with your suggestion totally.I think updating the hardcoded version string to be always in sync with the tag is something we need.

I imagine a manually triggered CD job that:

  • Requires an input like "2.5.0" or "v2.5.0" or "version 2.5.0"
  • Then, input will be cleaned and converted to "2.5.0" to maintain uniformity in all future releases (or fail if string is not in the expected format)
  • Update the swift file with sed command or something
  • Commit
  • Create a tag
  • Push commit and tag directly
  • (Then current script will realize about the pushed tag and make a release :) )

@nacho4d
Copy link
Member Author

nacho4d commented Jan 6, 2022

Do you think it is good we do this in next branch?

@tylervick
Copy link
Member

Yeah - especially if we modify the current -v flag I think it makes sense to put this in next to denote a breaking change. It also is easier to implement there when ArgumentParser is used.

I'm surprised that SPM doesn't have a solution for this.. But yeah a CD job like you outlined would make sense. Maybe a VERSION file that can be read at compile time and referenced/updated according to the current tag.

Having a central release job would work since we could do this and other things like update the homebrew repo and whatever else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants