Details

    • Improvement
    • Status: Closed
    • Trivial
    • Resolution: Done
    • 3.4.11
    • 3.5.0, 3.3.11, 3.4.11
    • gremlint, javascript
    • None

    Description

      Creating this task as a follow-up to https://issues.apache.org/jira/browse/TINKERPOP-2572.

      To make sure the result of running npm install is deterministic, package-lock.json should be committed along with package.json instead of being gitignored. This will prevent older package-lock.json files that may exist locally from earlier installs from being used to determine what versions to install when running npm install.

      I'm not 100% sure I understand how the Affects Version and Fix Version fields should be set when creating the Jira ticket. Feedback appreciated.

      Attachments

        Activity

          we usually just set the "affects version" to the oldest version where we see the problem (so typically just one value there and in this case would be 3.4.11 - sorry, shouldn't have said 3.3.11 originally). we usually set the fix version when we close the issue and set it to all the versions within which it was fixed. for this particular situation, you have a pretty simple administrative change. i think you would be within rights to have not bothered to create a JIRA and just did a commit/push as CTR - see the last bullet point in this section: https://tinkerpop.apache.org/docs/current/dev/developer/#rtc

          So, you would checkout 3.4-dev, make your change, commit locally with "CTR" in the comment (like i did earlier today here as an example). then, basically:

          git checkout 3.5-dev 
          git merge 3.4-dev
          git checkout master
          git merge 3.5-dev
          

          then push in reverse order:

          git push origin master
          git push origin 3.5-dev
          git push origin 3.4-dev
          
          spmallette Stephen Mallette added a comment - we usually just set the "affects version" to the oldest version where we see the problem (so typically just one value there and in this case would be 3.4.11 - sorry, shouldn't have said 3.3.11 originally). we usually set the fix version when we close the issue and set it to all the versions within which it was fixed. for this particular situation, you have a pretty simple administrative change. i think you would be within rights to have not bothered to create a JIRA and just did a commit/push as CTR - see the last bullet point in this section: https://tinkerpop.apache.org/docs/current/dev/developer/#rtc So, you would checkout 3.4-dev, make your change, commit locally with "CTR" in the comment (like i did earlier today here as an example). then, basically: git checkout 3.5-dev git merge 3.4-dev git checkout master git merge 3.5-dev then push in reverse order: git push origin master git push origin 3.5-dev git push origin 3.4-dev
          oyvindsabo Øyvind Sæbø added a comment -

          Fixed as CTR

          For gremlin-javascript (for 3.4-dev, 3.5-dev and master):
          https://github.com/apache/tinkerpop/commit/f52abb2277a3d9dd33ab216b83ec58c23c7d20a2

          For gremlint (for 3.5-dev and master). https://github.com/apache/tinkerpop/commit/c98d9ca0d81fe977d284afc768c2b94c422e1de0 

          oyvindsabo Øyvind Sæbø added a comment - Fixed as CTR For gremlin-javascript (for 3.4-dev, 3.5-dev and master): https://github.com/apache/tinkerpop/commit/f52abb2277a3d9dd33ab216b83ec58c23c7d20a2 For gremlint (for 3.5-dev and master). https://github.com/apache/tinkerpop/commit/c98d9ca0d81fe977d284afc768c2b94c422e1de0  

          looks good - you can actually "Close" issues when you complete them. we don't currently use the "Resolved" status. i've closed this one for you.

          spmallette Stephen Mallette added a comment - looks good - you can actually "Close" issues when you complete them. we don't currently use the "Resolved" status. i've closed this one for you.
          oyvindsabo Øyvind Sæbø added a comment -

          Thanks

          oyvindsabo Øyvind Sæbø added a comment - Thanks

          People

            oyvindsabo Øyvind Sæbø
            oyvindsabo Øyvind Sæbø
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 24h
                24h
                Remaining:
                Remaining Estimate - 24h
                24h
                Logged:
                Time Spent - Not Specified
                Not Specified