Meshcentral: Update

Created on 12 Jan 2020  路  6Comments  路  Source: Ylianst/MeshCentral

When I manually perform an update to meshserver, if the minor version goes up one digit, ie from 0.4.5-a to 0.4.6-a then I need to manually install with the version number

sudo npm install [email protected]

This is on Ubuntu 18.04 and may be because of the permissions that I've set
If just updating to a new 'letter', ie from 0.4.7-a to 0.4.7-h then it just works with the standard install

sudo npm install meshcentral

bug

Most helpful comment

Also, when I update I ALWAYS get these warnings - without operational impact

npm WARN meshcentral No description
npm WARN meshcentral No repository field.
npm WARN meshcentral No license field.

This is because we're installing meshcentral as if it were a dependency to an npm package that we're building, not downloading meshcentral's repo to where npm will treat it as the package itself. The difference being that when we run npm install meshcentral we install meshcentral in <current directory>\node_modules\meshcentral thus meshcentral's package.json is at <current directory>\node_modules\meshcentral\package.json and we don't have a package.json at <current directory>\package.json, which is where npm is looking for this information.

Oh... this is interesting. I may need to change my versions, I think @MailYouLater had mentioned before that using 1.2.3-a versions is not good. I need to look into this.

Regarding the quality of your versioning system: It's a bit unusual. I personally prefer the Major.Minor.Patch.Build versioning system, where the Major and Minor versions indicate a level of backward compatibility, the Patch number increases as new features or bug fixes are added to the code, and the Build number increases with each and every change, each of these being reset to 0 when the number of a higher significance changes. "Semantic versioning" (used by npm) doesn't allow this, instead it's Major.Minor.Patch where the significance of the number in the sequence indicates the level of backward compatibility and/or feature completeness and optionally Major.Minor.Patch-<pre-release tag> for versions that aren't considered stable yet. You seem to have a ... less useful (as a consumer) ... versioning system, where you use it more like Reserved.Bu.il-d, where the letter increases within the 'a-z' with each and every change, the last number in the version increases purely due to running out of letters in the 'a-z' sequence, the second number increases when you run out of digits in the '0-9' sequence, and the first version number is (so far) unused, apparently reserved for something in the future.

I think that the '.git' at the end of the URL is also not required

Not required due to the way GitHub is implemented, but preferred due to the fact not needing it is implementation specific and thus other git hosting providers may require it, so it's good to keep in the habit of using it here.

All 6 comments

Also, when I update I ALWAYS get these warnings - without operational impact

npm WARN meshcentral No description
npm WARN meshcentral No repository field.
npm WARN meshcentral No license field.

Oh... this is interesting. I may need to change my versions, I think @MailYouLater had mentioned before that using 1.2.3-a versions is not good. I need to look into this. I have also never figured out how to remove the 3 warnings... I have tried in the past. Any help from the community on this would be welcome. I have put in these fields (I think).

Not 100% sure on the description and license fields but it looks like the package.json file in node_modules\meshcentral has a misspelled url. See example below:
Current:
"repository": {
"type": "git",
"url": "git+https://github.com/Ylianst/MeshCentral.git"
},

Fix:
"repository": {
"type": "git",
"url": "git://github.com/Ylianst/MeshCentral.git"
},

Here's where I found the fix: https://exceptionshub.com/npm-warn-package-json-no-repository-field.html

I think that the '.git' at the end of the URL is also not required

Also, when I update I ALWAYS get these warnings - without operational impact

npm WARN meshcentral No description
npm WARN meshcentral No repository field.
npm WARN meshcentral No license field.

This is because we're installing meshcentral as if it were a dependency to an npm package that we're building, not downloading meshcentral's repo to where npm will treat it as the package itself. The difference being that when we run npm install meshcentral we install meshcentral in <current directory>\node_modules\meshcentral thus meshcentral's package.json is at <current directory>\node_modules\meshcentral\package.json and we don't have a package.json at <current directory>\package.json, which is where npm is looking for this information.

Oh... this is interesting. I may need to change my versions, I think @MailYouLater had mentioned before that using 1.2.3-a versions is not good. I need to look into this.

Regarding the quality of your versioning system: It's a bit unusual. I personally prefer the Major.Minor.Patch.Build versioning system, where the Major and Minor versions indicate a level of backward compatibility, the Patch number increases as new features or bug fixes are added to the code, and the Build number increases with each and every change, each of these being reset to 0 when the number of a higher significance changes. "Semantic versioning" (used by npm) doesn't allow this, instead it's Major.Minor.Patch where the significance of the number in the sequence indicates the level of backward compatibility and/or feature completeness and optionally Major.Minor.Patch-<pre-release tag> for versions that aren't considered stable yet. You seem to have a ... less useful (as a consumer) ... versioning system, where you use it more like Reserved.Bu.il-d, where the letter increases within the 'a-z' with each and every change, the last number in the version increases purely due to running out of letters in the 'a-z' sequence, the second number increases when you run out of digits in the '0-9' sequence, and the first version number is (so far) unused, apparently reserved for something in the future.

I think that the '.git' at the end of the URL is also not required

Not required due to the way GitHub is implemented, but preferred due to the fact not needing it is implementation specific and thus other git hosting providers may require it, so it's good to keep in the habit of using it here.

Just reporting that update this morning only went from v0.4.7-l to v0.4.7-z, and not to the v0.4.8- group

install [email protected] upgrades to that version, then a version less update goes through until 0.4.8-b

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PathfinderNetworks picture PathfinderNetworks  路  3Comments

hellofaduck picture hellofaduck  路  3Comments

darryl-h picture darryl-h  路  3Comments

unguzov picture unguzov  路  3Comments

robclay picture robclay  路  3Comments