Skip to content
This repository has been archived by the owner on Jun 16, 2018. It is now read-only.

Adding changes to push package to npm #35

Open
wants to merge 4 commits into
base: gh-pages
Choose a base branch
from
Open

Adding changes to push package to npm #35

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8ba03d4
Changing package.json for publishing in the npm
2roy999 Aug 1, 2017
b918585
Change package name
2roy999 Aug 1, 2017
4023c91
change packge version
2roy999 Aug 23, 2017
445b9e4
Change the version and the name of the package
2roy999 Aug 30, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "displaysystem",
"version": "1.0.0",
"name": "@first-lego-league/display",
Copy link
Member

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

Copy link
Member Author

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.

"version": "0.0.5",
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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)

Copy link
Member Author

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

Copy link
Member

@rikkertkoppes rikkertkoppes Aug 30, 2017 •
edited
Loading

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.

"description": "Display Systems",
"main": "config.js",
"scripts": {
Expand Down