Should we tag the code state when the publication was published?

[bdklahn]

@srinivvenkat @bryanleroylewis

https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md

I've copied in that markdown (at the time of this comment), below.

Use a tag To Mark the State of Any Code Referenced In a Publication

e.g., to add a tag to the commit (branch?) currently checked out.

git tag -a pub2019Sept16

To tag a past commit, simply find and add the hash.

git log
git tag -a pub2019Sept16 4a33129cfb03ba9c418846440601bb712c507c80

Like when commiting, your default editor (vim, in my case) should open to enable you to compose a complete (useful) message.

e.g., maybe include something like the following:

Code state for <title> publication https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007111

It might even be good to use the tag url when referencing the code in the publication, so people aren't confused if things have changed since the publication. It should still be apparent that/how code changed, when they see the other (newer) branches/commits which are available.
If the readme file mentions the publication, it could also note that tag url.

Tags don't automatically get pushed to remotes, so make sure to do that.

e.g.

git push origin pub2019Sept16

Just including people who might like this suggestion, or have additional input.
@HenningMortveit @shoops @dmachi

[HenningMortveit]

Brian, This is a very good point you bring up, one that we should address more broadly. I suppose this is done for EpiHiper when images are built. Do you, or anyone else, have thoughts about how we could manage this in a good way both inside and outside of SciDuct? Henning

…

On Mon, Mar 16, 2020 at 11:53 AM Brian Klahn ***@***.***> wrote: @srinivvenkat <https://github.com/srinivvenkat> @bryanleroylewis <https://github.com/bryanleroylewis> https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md I've copied in that markdown (at the time of this comment), below. Use a tag <https://git-scm.com/book/en/v2/Git-Basics-Tagging> To Mark the State of Any Code Referenced In a Publication e.g., to add a tag to the commit (branch?) currently checked out. git tag -a pub2019Sept16 That should open your default editor (vim, in my case) to enable you to compose a complete (useful) message. e.g., maybe include something like the following: Code state for <title> publication https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007111 It might even be good to use the tag url when referencing the code in the publication, so people aren't confused if things have changed since the publication. It should still be apparent that/how code changed, when they see the other (newer) branches/commits which are available. To tag a past commit, simply find and add the hash. git log git tag -a pub2019Sept16 4a33129 *Tags don't automatically get pushed to remotes, so make sure to do that.* e.g. git push origin pub2019Sept16 Just including people who might like this suggestion, or have additional input. @HenningMortveit <https://github.com/HenningMortveit> @shoops <https://github.com/shoops> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKD2SZNJKPNMRMPXOOEVC7TRHZDN5ANCNFSM4LML3UCQ> .

[shoops]

Hello Henning and Brian, In my opinion this is common software development practice. Independent from whether you publish a paper or not you create version or releases of your software. In github this is easily done by using tags. A tag such 1.0.4 will automatically create a release in github. Just have a look at: https://github.com/NSSAC/EpiHiper-code/releases This releases can be annotated and augmented with additional download packages: https://github.com/copasi/COPASI/releases/tag/Build-217 Such an URL should the be dded as a reference in a publication in addition to the Website/Documentation or other resources provided on the Web. Thanks, Stefan

…

On Mon, 2020-03-16 at 13:43 -0700, Henning S Mortveit wrote: Brian, This is a very good point you bring up, one that we should address more broadly. I suppose this is done for EpiHiper when images are built. Do you, or anyone else, have thoughts about how we could manage this in a good way both inside and outside of SciDuct? Henning On Mon, Mar 16, 2020 at 11:53 AM Brian Klahn < ***@***.***> wrote: > @srinivvenkat <https://github.com/srinivvenkat> @bryanleroylewis > <https://github.com/bryanleroylewis> > > https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md > > I've copied in that markdown (at the time of this comment), below. > Use a tag <https://git-scm.com/book/en/v2/Git-Basics-Tagging> To Mark the > State of Any Code Referenced In a Publication > > e.g., to add a tag to the commit (branch?) currently checked out. > > git tag -a pub2019Sept16 > > That should open your default editor (vim, in my case) to enable you to > compose a complete (useful) message. > > e.g., maybe include something like the following: > > Code state for <title> publication > https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007111 > > It might even be good to use the tag url when referencing the code in the > publication, so people aren't confused if things have changed since the > publication. It should still be apparent that/how code changed, when they > see the other (newer) branches/commits which are available. > > To tag a past commit, simply find and add the hash. > > git log > git tag -a pub2019Sept16 4a33129 > > *Tags don't automatically get pushed to remotes, so make sure to do that.* > > e.g. > > git push origin pub2019Sept16 > > Just including people who might like this suggestion, or have additional > input. > @HenningMortveit <https://github.com/HenningMortveit> @shoops > <https://github.com/shoops> > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#7>;, or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AKD2SZNJKPNMRMPXOOEVC7TRHZDN5ANCNFSM4LML3UCQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bdklahn]

Hello Henning and Brian, My tagging you in the issue <#7> having that title might have been confusing. Yes, tagging is common software practice. I was just adding you to an issue instance <#7> where this tip <https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md> might be of relevance to people. That's all. I think Srini had previously been reluctant to mess with his original PatchSim code repo, as it represented, to him, a work specifically for a paper. So I made that GitHub issue as kind of a way to let him know that the state at publication can be annotated and preserved. So that issue title wasn't a general question, but more like a suggested request to the code authors(s). The general part of this, I guess, is that we all might use tags (in addition to all the common usage of them), to annotate the exact code state at publication time. And it might be a better practice to put a link to that specific code state, via tag url, vs general repo url, when the code is referenced in the publication. What Stefan might be pointing out is that, often, referenced code is already pointing to a tag, because a authors are using a specific (git-tagged) release or version. But one-off-like software like this often doesn't already have any common tags. So creation of one(s), relating to any publication(s) might be useful to create. Thanks, Brian Brian On Mon, Mar 16, 2020 at 6:03 PM Stefan Hoops <[email protected]> wrote:

…

Hello Henning and Brian, In my opinion this is common software development practice. Independent from whether you publish a paper or not you create version or releases of your software. In github this is easily done by using tags. A tag such 1.0.4 will automatically create a release in github. Just have a look at: https://github.com/NSSAC/EpiHiper-code/releases This releases can be annotated and augmented with additional download packages: https://github.com/copasi/COPASI/releases/tag/Build-217 Such an URL should the be dded as a reference in a publication in addition to the Website/Documentation or other resources provided on the Web. Thanks, Stefan On Mon, 2020-03-16 at 13:43 -0700, Henning S Mortveit wrote: > Brian, > > This is a very good point you bring up, one that we should address > more > broadly. I suppose this is done for EpiHiper when images are built. > Do you, > or anyone else, have thoughts about how we could manage this in a > good way > both inside and outside of SciDuct? > > Henning > > > > > On Mon, Mar 16, 2020 at 11:53 AM Brian Klahn < > ***@***.***> > wrote: > > > @srinivvenkat <https://github.com/srinivvenkat> @bryanleroylewis > > <https://github.com/bryanleroylewis> > > > > > https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md > > > > I've copied in that markdown (at the time of this comment), below. > > Use a tag <https://git-scm.com/book/en/v2/Git-Basics-Tagging> To > Mark the > > State of Any Code Referenced In a Publication > > > > e.g., to add a tag to the commit (branch?) currently checked out. > > > > git tag -a pub2019Sept16 > > > > That should open your default editor (vim, in my case) to enable > you to > > compose a complete (useful) message. > > > > e.g., maybe include something like the following: > > > > Code state for <title> publication > > > https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007111 > > > > It might even be good to use the tag url when referencing the code > in the > > publication, so people aren't confused if things have changed since > the > > publication. It should still be apparent that/how code changed, > when they > > see the other (newer) branches/commits which are available. > > > > To tag a past commit, simply find and add the hash. > > > > git log > > git tag -a pub2019Sept16 4a33129 > > > > *Tags don't automatically get pushed to remotes, so make sure to do > that.* > > > > e.g. > > > > git push origin pub2019Sept16 > > > > Just including people who might like this suggestion, or have > additional > > input. > > @HenningMortveit <https://github.com/HenningMortveit> @shoops > > <https://github.com/shoops> > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#7>;, or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AKD2SZNJKPNMRMPXOOEVC7TRHZDN5ANCNFSM4LML3UCQ > > > > . > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHAWUHFFSXWXR3MFL2TTCDRH2O33ANCNFSM4LML3UCQ> .

[HenningMortveit]

Brian, I appreciate you bringing this up. It is certainly something we should do for our own sanity to better match code versions, publications and studies. I like SciDuct as a point where this can be more readily enforced and managed. Henning On Mon, Mar 16, 2020 at 6:34 PM Brian Klahn <[email protected]> wrote:

…

Hello Henning and Brian, My tagging you in the issue <#7> having that title might have been confusing. Yes, tagging is common software practice. I was just adding you to an issue instance <#7> where this tip <https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md > might be of relevance to people. That's all. I think Srini had previously been reluctant to mess with his original PatchSim code repo, as it represented, to him, a work specifically for a paper. So I made that GitHub issue as kind of a way to let him know that the state at publication can be annotated and preserved. So that issue title wasn't a general question, but more like a suggested request to the code authors(s). The general part of this, I guess, is that we all might use tags (in addition to all the common usage of them), to annotate the exact code state at publication time. And it might be a better practice to put a link to that specific code state, via tag url, vs general repo url, when the code is referenced in the publication. What Stefan might be pointing out is that, often, referenced code is already pointing to a tag, because a authors are using a specific (git-tagged) release or version. But one-off-like software like this often doesn't already have any common tags. So creation of one(s), relating to any publication(s) might be useful to create. Thanks, Brian Brian On Mon, Mar 16, 2020 at 6:03 PM Stefan Hoops ***@***.***> wrote: > Hello Henning and Brian, > > In my opinion this is common software development practice. Independent > from whether you publish a paper or not you create version or releases > of your software. In github this is easily done by using tags. A tag > such 1.0.4 will automatically create a release in github. Just have a > look at: > https://github.com/NSSAC/EpiHiper-code/releases > > This releases can be annotated and augmented with additional download > packages: > https://github.com/copasi/COPASI/releases/tag/Build-217 > > Such an URL should the be dded as a reference in a publication in > addition to the Website/Documentation or other resources provided on > the Web. > > Thanks, > Stefan > > > > On Mon, 2020-03-16 at 13:43 -0700, Henning S Mortveit wrote: > > Brian, > > > > This is a very good point you bring up, one that we should address > > more > > broadly. I suppose this is done for EpiHiper when images are built. > > Do you, > > or anyone else, have thoughts about how we could manage this in a > > good way > > both inside and outside of SciDuct? > > > > Henning > > > > > > > > > > On Mon, Mar 16, 2020 at 11:53 AM Brian Klahn < > > ***@***.***> > > wrote: > > > > > @srinivvenkat <https://github.com/srinivvenkat> @bryanleroylewis > > > <https://github.com/bryanleroylewis> > > > > > > > > > https://github.com/NSSAC/Coding-Tips-And-Tricks/blob/master/git/readme.md > > > > > > I've copied in that markdown (at the time of this comment), below. > > > Use a tag <https://git-scm.com/book/en/v2/Git-Basics-Tagging> To > > Mark the > > > State of Any Code Referenced In a Publication > > > > > > e.g., to add a tag to the commit (branch?) currently checked out. > > > > > > git tag -a pub2019Sept16 > > > > > > That should open your default editor (vim, in my case) to enable > > you to > > > compose a complete (useful) message. > > > > > > e.g., maybe include something like the following: > > > > > > Code state for <title> publication > > > > > > https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007111 > > > > > > It might even be good to use the tag url when referencing the code > > in the > > > publication, so people aren't confused if things have changed since > > the > > > publication. It should still be apparent that/how code changed, > > when they > > > see the other (newer) branches/commits which are available. > > > > > > To tag a past commit, simply find and add the hash. > > > > > > git log > > > git tag -a pub2019Sept16 4a33129 > > > > > > *Tags don't automatically get pushed to remotes, so make sure to do > > that.* > > > > > > e.g. > > > > > > git push origin pub2019Sept16 > > > > > > Just including people who might like this suggestion, or have > > additional > > > input. > > > @HenningMortveit <https://github.com/HenningMortveit> @shoops > > > <https://github.com/shoops> > > > > > > — > > > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > > > <#7>;, or unsubscribe > > > < > > > https://github.com/notifications/unsubscribe-auth/AKD2SZNJKPNMRMPXOOEVC7TRHZDN5ANCNFSM4LML3UCQ > > > > > > . > > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub, or unsubscribe. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#7 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAHAWUHFFSXWXR3MFL2TTCDRH2O33ANCNFSM4LML3UCQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKD2SZOG5IF3L22NDXSELXTRH2SPFANCNFSM4LML3UCQ> .