Here’s a grep command to do that: grep “version\”\:” bower_components/thepackagename/.bower.json Also, a command to see versions of all bower components for the project – this list can be a handy CI artefact: grep “version\”\:” bower_components/*/.bower.json
My strategy is to let your VCS tags do it for you (git shown here). Add this to your application.rb: # Only attempt update on local machine if Rails.env.development? # Update version file from latest git tag File.open(‘config/version’, ‘w’) do |file| file.write `git describe –tags –always` # or equivalent end end config.version = File.read(‘config/version’) You … Read more
It’s your call, but the Semantic Versioning Standard recommends 0.1.0: The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
Well, we could trick sort -V by adding a dummy character at the end of the string for lines that do not contain a hyphen: $ echo “$versions” | sed ‘/-/!{s/$/_/}’ | sort -V | sed ‘s/_$//’ v1.4.0-alpha v1.4.0-alpha1 v1.4.0-patch v1.4.0-patch2 v1.4.0-patch9 v1.4.0-patch10 v1.4.0 v1.5.0-alpha v1.5.0-alpha1 v1.5.0-alpha2 v1.5.0-patch v1.5.0-patch1 v1.5.0 Underscore lexically sorts after hyphen. … Read more
The major version number is all you need for a web service. Because your consumers are only concerned about backward incompatible changes, and (if you’re following semantic versioning correctly) those will only be introduced when a new major version is released. All other changes (including new features, bugfixes, patches etc.) should be ‘safe’ for your … Read more
The SemVer spec gives you a lot of flexibility. Nothing in the spec precludes your using the numbered scenario you describe in your original post. Your alternative suggestion is also valid, as far as SemVer is concerned. Both scenarios start out with the 0.y.z form, which is meant to be used for initial development leading … Read more
Public API refers to the “point of access” that the external world (users, other programs and/or programmers, etc) have to your software. E.g., if you’re developing a library, the public API is the set of all the methods invokations that can be made to your library. There is understanding that, unless a major version changes, … Read more
You cannot set 0.2.1-alpha automatically, but 0.2.1-alpha.0 is possible. npm version supports a –preid option to specify the prefix of prereleases. It’s available in combination with pre* versions. Example 1. Make the alpha of next major version: # 1.2.3 => 2.0.0-alpha.0 npm version premajor –preid alpha Example 2. Bump alpha to beta: # 2.0.0-alpha.0 => … Read more
You can unpublish a specific version, and then republish it: npm unpublish myModule@1.2.3 And then republish the version. This works if the module is hosted on your own npm repo, but for registry.npmjs.org, you won’t be able to reuse the version number after unpublishing, and there’s a time-limit (72 hours) after which you can no … Read more
TLDR I have not seen prelease versions utilized pre-1.0.0. It seems fairly pointless since the public API is not finalized yet. They become useful after 1.0.0 is released. So when are prelease versions useful? From semver.org: Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is … Read more