[FOLIO-1704] Expose next-major features/migration through npm pre-releases. Created: 15/Jan/19 Updated: 04/Jun/20 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Story | Priority: | P3 |
| Reporter: | John Coburn | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | RFC | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||
| Sprint: | |||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||
| Description |
| Comments |
| Comment by Jason Skomorowski [ 17/Jan/19 ] |
|
This is a great improvement to our process. As we move towards production, actual releases start to take on a bit more gravity so it's important to be able to articulate a dependency on unreleased features from other modules when developing what is perhaps the application that inspired their creation. My concern is: will this break our CI system? Or will it Just Work because it'll take the the last digit and so can happily do its version modification with the number following pre eg. 6.0.0-pre.1 will become 6.0.0-pre.10001 and things will be fine? While I'm completely sold on the pre tag, I am not at all convinced by the idea of a snapshot or an lts tag
|
| Comment by Jason Skomorowski [ 22/Jan/19 ] |
|
...as pointed out last Thursday (I think by Matt?)--yes, this breaks the way we do CI because tagged NPM versions are only pulled in explicitly and so changing the package.json in master to a pre version will mean that only gets pulled in by things that explicitly depend on the pre tag and so if, eg, there is a pre version of the stripes framework we'll wind up (unworkably) with apps depending on the non-pre one. Maybe the solution is something like having the CI npms published to a CI tag with versions that having nothing to do with our usual ones and a stripes-framework and platform for CI purposes that point at those? The goal is testing tip-of-master for all packages so nuanced dependencies aren't relevant there? (unless we decide to get back to a place where we can have two copies of stripes-components...) |
| Comment by Matthew Jones [ 23/Jan/19 ] |
We've used (in a limited scope) and documented the pre-release syntax before. The results didn't break CI, but CI did mangle the expected suffix a bit. See my comment in
Using the pre-release syntax would be a more elegant solution our snapshot system which is not following semver. This would require some changes to CI of course, but with the introduction of the stripes framework as a peerDependency, I think we are past some of the earlier challenges that prompted the use of inflated patch numbers in CI. We should be able to establish a process to capture the opt-in nature of the pre-release for stripes-* modules and publish a pre-release of stripes (framework) accordingly. Note: we will also need to update the existing snapshot logic in Okapi as well.
I don't think we should use the pre-release syntax for LTS. A version like "1.0.0-anything" implies a version leading up to "1.0.0" and not after it. LTS versions could be called out via documentation rather than an NPM mechanism to indicate this. |