SPIKE: consider pre-release syntax for UI module snapshots
Description
Environment
Potential Workaround
Checklist
hideTestRail: Results
Activity
Matt Jones August 16, 2018 at 8:22 PM
What does this look like when building a platform in CI?
Because of the pre-release suffix, we won't be able to use "latest" or ">=0.0.0" for dependencies (the latter of which basically says "I'll take any version"). We will have to be more specific in knowing the latest intended major.minor.patch, but could take the latest snapshot:
Matt Jones August 16, 2018 at 8:17 PM
To make this work, what would the process look like? Here is one suggestion:
Step | Example |
|---|---|
Typical development in the master branch maintains a package.json matching x.y.z-SNAPSHOT, where "x.y.z" represents one patch number increment over the prior release | 1.2.4-SNAPSHOT when prior release was 1.2.3 |
Changelog.md reflects progress toward version x.y.z | 1.2.4 (IN PROGRESS) |
As merges into master are made, Jenkins/CI publishes packages as x.y.z.-SNAPSHOT.buildnumber to npm-folioci | 1.2.4-SNAPSHOT.107 (npm-folioci) |
When creating a release branch, developer follows typical release process reconciling changelog as necessary. New: The developer omits "-SNAPSHOT" from the package.json | 1.2.4 |
A merge without "-SNAPSHOT" instructs Jenkins to publish version x.y.z to npm-folio, in addition to npm-folioci. Tagged automatically. | 1.2.4 (npm-folio) and 1.2.4.SNAPSHOT.108 (npm-folioci) |
Then package.json version is automatically bumped by a patch number and -SNAPSHOT is appended back to the package.json in preparation for more work | 1.2.5-SNAPSHOT |
At any point during subsequent development, should a new feature be added (rather than fix), the minor version is bumped. | 1.3.0-SNAPSHOT |
Likewise, should a breaking change be introduced the major version is bumped. In either case "-SNAPSHOT" remains. | 2.0.0-SNAPSHOT |
Note:
This suggestion maintains the pre-release suffix (SNAPSHOT) in the master branch, using the omission of the suffix as a trigger to publish to npm-folio. This could be reversed, however, where CI automatically appends "-SNAPSHOT" on non-release merges, using another trigger (the tag?) to prompt CI to publish to npm-folio. That said, having "-SNAPSHOT" exist in master may give clarity to the fact that a developer cloning master is working on unreleased code, particularly when developing in a workspace environment that has a lot of modules in play.
Details
Assignee
UnassignedUnassignedReporter
Matt JonesMatt JonesPriority
P3Story Points
5Sprint
NoneDevelopment Team
Core: PlatformTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Reporter
Matt JonesPriority
P3
This ticket is being creating because I don't want 's suggestion in FOLIO-1344 get get overlooked:
Use of this pre-release syntax will also enable our build numbers to adhere to semver. Currently our npm-folioci build numbers can be misleading at the patch segment. For example, version 1.2.3000123 generated from a package defining itself as 1.2.3, technically can be satisfied by a request for ^1.2.4. Also, determining compatibility with our own npm-folio can also be a challenge. For example, is 1.2.3000456 actually the CI build of 1.2.3 or a build working toward 1.3.0?
One challenge, as I understand from the earlier JIRAs on this topic (FOLIO-690 and FOLIO-696), is with pulling in the latest versions of stripes dependencies defined below the platform's package.json (eg. platform > ui-app > stripes-smart-components > stripes-components). Grouping our stripes-* dependencies () should alleviate this, by pointing the app/platform to a version/snapshot of the framework which takes care of the underlying dependencies.