[FOLIO-696] Rethink NPM package versioning for generating packages from HEAD. Created: 26/Jun/17  Updated: 12/Nov/18  Resolved: 21/Jul/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: John Malconian Assignee: John Malconian
Resolution: Done Votes: 0
Labels: build-release, ci, sprint18
Remaining Estimate: Not Specified
Time Spent: 5 hours, 30 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-690 folio-testing.aws.indexdata.com does ... Closed
relates to FOLIO-1450 Revise FOLIO release and deployment p... Open
Sprint:

 Description   

Using pre-release version designations such as '-SNAPSHOT' with NPM packages is not ideal due to issues with the way NPM resolves dependent packages that use pre-release versioning. See FOLIO-690 Closed . Another possible solution is to use "super-high" patch release versions to represent NPM CI packages generated from tip of master instead of pre-release designations.



 Comments   
Comment by Mike Taylor [ 19/Jul/17 ]

From my perspective, the way you're doing this right now seems pretty much perfect.

Comment by John Malconian [ 21/Jul/17 ]

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.

Generated at Thu Feb 08 23:07:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.