Is it OK to update code on repository after publication?












22















Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).



I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).










share|improve this question







New contributor




altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

























    22















    Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).



    I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
    Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).










    share|improve this question







    New contributor




    altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      22












      22








      22








      Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).



      I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
      Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).










      share|improve this question







      New contributor




      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      Journals consider that is good practice to release script and codes to repeat the published results, and many of us I think agree with this practice. Code are typically deposited in software version control repositories (e.g., GitHub or BitBucket).



      I wonder if updating the codes during reviewing process or after publications (which in my opinion is quite important, in general) remains a good practice.
      Maybe the obvious answer is yes, but for example it is certainly not good to modify the data deposited for a published article (or modify its pre-print in a pre-print server).







      publications code






      share|improve this question







      New contributor




      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question







      New contributor




      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question






      New contributor




      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 6 hours ago









      altrowarealtroware

      2112




      2112




      New contributor




      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      altroware is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          3 Answers
          3






          active

          oldest

          votes


















          32














          Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.



          What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.



          This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.






          share|improve this answer



















          • 4





            Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

            – Kevin
            3 hours ago






          • 3





            Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

            – JoL
            3 hours ago













          • Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

            – FuzzyLeapfrog
            3 hours ago



















          -1














          If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:



          1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.



          2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.



          3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.



          4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.



          This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.






          share|improve this answer








          New contributor




          awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





















          • While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

            – jakebeal
            52 mins ago



















          -2














          system/app/MTKLogger/MTKLogger.apk 



          /*






          share|improve this answer








          New contributor




          Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.




















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "415"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });






            altroware is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2facademia.stackexchange.com%2fquestions%2f124616%2fis-it-ok-to-update-code-on-repository-after-publication%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            32














            Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.



            What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.



            This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.






            share|improve this answer



















            • 4





              Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

              – Kevin
              3 hours ago






            • 3





              Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

              – JoL
              3 hours ago













            • Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

              – FuzzyLeapfrog
              3 hours ago
















            32














            Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.



            What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.



            This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.






            share|improve this answer



















            • 4





              Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

              – Kevin
              3 hours ago






            • 3





              Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

              – JoL
              3 hours ago













            • Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

              – FuzzyLeapfrog
              3 hours ago














            32












            32








            32







            Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.



            What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.



            This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.






            share|improve this answer













            Absolutely yes! There is no reason to stop a project from evolving just because you've published about it.



            What would be good to do, however, is to identify the version current at the time of publication with a release version or other similar sort of tag. You can point to the specific tag in the publication and also have the repository tag point to the publication through its associated comment text.



            This will allow a reader to have the best of both worlds: access to both the most updated information and also to the precise version associated with the publication if they need it.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 6 hours ago









            jakebealjakebeal

            145k30522763




            145k30522763








            • 4





              Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

              – Kevin
              3 hours ago






            • 3





              Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

              – JoL
              3 hours ago













            • Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

              – FuzzyLeapfrog
              3 hours ago














            • 4





              Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

              – Kevin
              3 hours ago






            • 3





              Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

              – JoL
              3 hours ago













            • Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

              – FuzzyLeapfrog
              3 hours ago








            4




            4





            Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

            – Kevin
            3 hours ago





            Git specifically has a feature for tagging specific commits: git-scm.com/book/en/v2/Git-Basics-Tagging

            – Kevin
            3 hours ago




            3




            3





            Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

            – JoL
            3 hours ago







            Besides a tag or release version, it would be good to include the immutable hash of the last commit at the time of publication. That way, the reader of the publication can be certain of the corresponding code. Tags can be moved and versioned releases can be modified, but hashes cannot. They're cryptographically linked to the code.

            – JoL
            3 hours ago















            Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

            – FuzzyLeapfrog
            3 hours ago





            Zenodo allows to add different DOIs to different code versions, e.g. using GitHub. guides.github.com/activities/citable-code

            – FuzzyLeapfrog
            3 hours ago











            -1














            If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:



            1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.



            2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.



            3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.



            4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.



            This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.






            share|improve this answer








            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





















            • While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

              – jakebeal
              52 mins ago
















            -1














            If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:



            1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.



            2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.



            3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.



            4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.



            This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.






            share|improve this answer








            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





















            • While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

              – jakebeal
              52 mins ago














            -1












            -1








            -1







            If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:



            1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.



            2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.



            3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.



            4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.



            This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.






            share|improve this answer








            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.










            If you can improve your code, you have a duty as a programmer to do so. However, you need to be aware of what kind of changes you are making:



            1) Corrective Change. if you are changing a part of your logic and algorithms, specify that it is changing, as the results will also change. Re-run of the experiment is required.



            2) Perfective: Make the code faster or more efficient. This does not change the data, but looks nicer. Re-run of experiment is required if the data changes.



            3) Adaptive: Change the input or run-time environment. For example, a hardware change may necessitate a change in the software. This only requires re-running the experiment if the input data changes.



            4) Disconnected/preventative: Change the underlying model that your code is based on. Re-run is required.



            This was what I learned in my Data Provenance class, when talking about simulation algorithms, but the premise should still be the same.







            share|improve this answer








            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            share|improve this answer



            share|improve this answer






            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.









            answered 1 hour ago









            awsirkisawsirkis

            1




            1




            New contributor




            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.





            New contributor





            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






            awsirkis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.













            • While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

              – jakebeal
              52 mins ago



















            • While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

              – jakebeal
              52 mins ago

















            While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

            – jakebeal
            52 mins ago





            While I appreciate that the categorization of changes can be interesting, can you relate it to the question that has been asked?

            – jakebeal
            52 mins ago











            -2














            system/app/MTKLogger/MTKLogger.apk 



            /*






            share|improve this answer








            New contributor




            Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.

























              -2














              system/app/MTKLogger/MTKLogger.apk 



              /*






              share|improve this answer








              New contributor




              Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.























                -2












                -2








                -2







                system/app/MTKLogger/MTKLogger.apk 



                /*






                share|improve this answer








                New contributor




                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.










                system/app/MTKLogger/MTKLogger.apk 



                /*







                share|improve this answer








                New contributor




                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                share|improve this answer



                share|improve this answer






                New contributor




                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                answered 45 mins ago









                Kimi QlateKimi Qlate

                1




                1




                New contributor




                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





                New contributor





                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






                Kimi Qlate is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






















                    altroware is a new contributor. Be nice, and check out our Code of Conduct.










                    draft saved

                    draft discarded


















                    altroware is a new contributor. Be nice, and check out our Code of Conduct.













                    altroware is a new contributor. Be nice, and check out our Code of Conduct.












                    altroware is a new contributor. Be nice, and check out our Code of Conduct.
















                    Thanks for contributing an answer to Academia Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2facademia.stackexchange.com%2fquestions%2f124616%2fis-it-ok-to-update-code-on-repository-after-publication%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Ponta tanko

                    Tantalo (mitologio)

                    Erzsébet Schaár