1

I have an R project that generates some Solr and RDF output. The project is in a GitHub repo, and I have a pre-release tagged 1.0.0

My team has decided that any knowledge artifacts we create should have an internal indication of the version of the software that created them.

Currently, I manually enter the release tag into a JSON configuration file after manually/interactively making the release on the GitHub website.

Could I either

  • automatically enter the release number into the config file when the release is built
  • automatically determine the release version when running the R scripts

And are either of those approaches good ideas? A user could theoretically make local changes to the R code and get out of sync with the cited release, right?

Mark Miller
  • 3,011
  • 1
  • 14
  • 34
  • 1
    CVS has the concept of `$Id$`, but [`git` does not](https://stackoverflow.com/q/384108/3358272). https://stackoverflow.com/a/5022854/3358272 and https://stackoverflow.com/a/11807529/3358272 talk about `.gitattributes`, which gives the current file *blob* (not commit), which might be sufficient to identify which file it is. Otherwise, I think you'll need to run an external script when you "deploy" the software that does the `$Id$` thing. – r2evans Oct 02 '20 at 16:16
  • Can you add more details about what happens to this project once you push it to GitHub and create a release? Do people come download it directly from GitHub? Do people clone it, or download zips of the source from GitHub? Do binaries get built from it? Does it get published to a package manager? – Soren Bjornstad Oct 03 '20 at 22:12

0 Answers0