|
| ▲ | OJFord a day ago | parent | next [-] |
| If it's baked into the tool (can run offline) then it would be unavoidable, need a new version to get a new release on the package manager. 1.2.3 -> 1.2.3+1 (or +anything, date, whatever) could arguably be idiomatic semver though - that's what you do for packaging changes, like updating the description or categories to file it under etc. without actually changing the program. |
| |
| ▲ | chrisandchris a day ago | parent [-] | | > (can run offline) And yet you need internet access when running the package with npx, even though the package is already locally installed. At least, I can't use npx on so e of my VMs which do not have access to the internet. It just takes forever to atart (and I get annoyed after some minutes). |
|
|
| ▲ | pixl97 a day ago | parent | prev [-] |
| The particular problem here is if you started out doing it wrong then changing your update behavior would break everyone's scripting around it. By changing the 'code version' everyones CI/CD system just keeps working the same way as any other package. |
| |
| ▲ | darkwater 9 hours ago | parent [-] | | I understand, but you can just have a committed config file that tells which definitions version to use and/or URL to retrieve (so you can mirror it on your infra or serve a patched version for your use case). |
|
