-
Notifications
You must be signed in to change notification settings - Fork 7
Adding changes to push package to npm #35
base: gh-pages
Are you sure you want to change the base?
Conversation
package.json
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "displaysystem", | |||
"version": "1.0.0", | |||
"name": "@first-lego-league/display", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather call it displaysystem, to be consistent with the already established name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no problem changing it to displaysystem
i just thought it's clearer only display
.
package.json
Outdated
"name": "displaysystem", | ||
"version": "1.0.0", | ||
"name": "@first-lego-league/display", | ||
"version": "0.0.5", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backing up versions is never a good idea. What is the rationale behind it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have backtrack it. because i didn't want to upload a beta version of the code as version 1. I believe it's ok since the I was the first to upload it to npm under this name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way to do that is to create a beta version like 1.0.0-beta.1, see http://semver.org/
That way, a full release always takes precedence when installing from npm.
Also, I am not really happy to have beta versions in npm anyway, this is very confusing to end users. If you want to test stuff locally, use npm link, do not publish stuff that is not ready (i.e. not reviewed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the beta might be a better way to go.
But the link can't be used because I need the npm package to be download when I'm building the installer.
Anyway I would change the version to 1.0.0-beta.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would propose the same as in clock:
- change the version to 1.0.x
- name should be displaysystem
- create a PR, I will merge that to gh-pages
And then
- create a beta branch, versioned 1.1.0-beta.1
- create a PR, I will merge that into a beta branch
- publish that beta on npm if you wish
That way, the versions are increasing always. Note that 1.1.0-beta.1 is a lower version than 1.1.0 automatically
The rationale is that I rather not publish beta versions anyway (for such a small project), but I
can understand it may be beneficial to your progress. This way, the beta is still accessible (as a branch), but not in the danger of being used accidentally
Also, if you want, just publish the main branch (gh-pages) as version 1.0.x in npm. I don't really see the need for having a beta there in this case.
No description provided.