Conform to semantic versioning
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript, nodejs
- Domain
- release
Research direction
Start with package.json and inspect how the current 0.0.X version is defined and updated. Read the linked npm semantic-versioning guidance, then trace any version or publishing workflow referenced by the package metadata. Done means the package follows an agreed semantic-versioning scheme and its metadata supports the intended npm update behavior.
Written by the indexing model from the issue text.
Description
The current versioning for the package does not follow common practices for the environment it's being packaged for. Most npm packages follow semantic versioning, which aids both the consuming engineers as well as the distributing engineers.
Currently the versioning has been done all within the "patch" decimal place, example: 0.0.X
This has a few side effects when utilizing npm as your distribution platform, because there are prefixes that can be applied within the package.json that depend on the versioning adhering to semantic versioning. An example of that would be the ^ prefix, example: "cybersource-rest-client-node": "^0.0.30" this would mean that when installing the package npm will take any update to 'minor' or 'patch', in the current context of writing this would be 0.0.52. This feature is there to allow for an easier development experience for the engineers making the package as they can push more regularly, and allows for the consuming engineers to not have to be so diligent about monitoring small updates for all of the imported packages in their projects.
- Dominant language
- JavaScript
- Stars
- 50
- Forks
- 50
- Avg merge
- 19m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CyberSource/cybersource-rest-client-node
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative insteadOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
CyberSource/cybersource-rest-client-node#173 · 1 reaction ·
-
Difficulty 3/5 Half a day Newbie friendliness 35/100
CyberSource/cybersource-rest-client-node#148 · 2 comments ·
All issues in CyberSource/cybersource-rest-client-node
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
curriculum documentation quality
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
githubnext/gh-aw-workshop#3897 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
agent/quality hive/hosted-available-lke648397-260827-5n31 quality testing
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
Maintainers usually reply within 1 day