|
Well, not really Mike Taylor. It's inconsistent across modules. At any rate I've implemented a scheme similar to the one you suggested in FLIO-690. That is, inflate the patch version on each NPM package to an artificially high number. Specifically, two '0's plus the Jenkins number ($BUILD_NUMBER) are added to the the existing patch version specified in package.json. For example, if the existing package.json has version 2.3.4, then the new snapshot version will be 2.3.40051 (assuming Jenkins build number 51 of the npm package).
There is one exception due to a SemVer limitation. If the patch version is '0' in the above example, 2.3.00051 is not a valid SemVer. Therefore, when the existing patch version is '0', it will be increased to '1' and the new snapshot version for 2.3.0 would become 2.3.10051. This exception handling could potentially cause a problem when the base version eventually becomes 2.3.1, however, I don't think it will because, by that time, the Jenkins build number would be sufficiently higher.
|