I've added a tag to the repo, v0.1.0, to mark our submission for an ASHE 2020 symposium.
With other projects, tagging has been very useful. For an example, I tag updates to my EDH7916 course website so that students and I have a record of all changes. For research projects, tagging helps me find the repo status associated with particular milestones: proposal submissions, working paper releases, publications, etc. IMO, this takes advantage of git's version control (i.e. no need to save paper_ashe.pdf, paper_journal.pdf, etc) and supports replicability.
Projects that use tags (and GitHub's associated Releases) often follow semantics such that
v<1>.<2>.<3> translates to
<1>: Major release
<2>: Minor release
<3>: Patch (bug fix)
This structure doesn't translate exactly to our work, but in general I suggest:
I've added a tag to the repo, v0.1.0, to mark our submission for an ASHE 2020 symposium.
With other projects, tagging has been very useful. For an example, I tag updates to my EDH7916 course website so that students and I have a record of all changes. For research projects, tagging helps me find the repo status associated with particular milestones: proposal submissions, working paper releases, publications, etc. IMO, this takes advantage of git's version control (i.e. no need to save paper_ashe.pdf, paper_journal.pdf, etc) and supports replicability.
Projects that use tags (and GitHub's associated Releases) often follow semantics such that
v<1>.<2>.<3>translates to<1>: Major release<2>: Minor release<3>: Patch (bug fix)This structure doesn't translate exactly to our work, but in general I suggest:
<1>: Paper(s) / Presentations of new material<2>: Merges, paper/conference submissions, secondary presentations<3>: Code fixes, writing edits, general small changes of noteBecause we are in the early stages, first tag is set as v0.1.0.
A couple of notes:
Thoughts? Concerns?