[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:
Relates
relates to FOLIO-895 Review publish procedure for pre-rele... Open
relates to FOLIO-1415 SPIKE: consider pre-release syntax fo... Open
relates to FOLIO-2092 use -alpha.NNN pre-release version sy... Blocked
Sprint:
Development Team: Core: Platform

 Description   

Currently, release branches for <next-major-version> are created for stripes-components once breaking changes are developed. These branches exist long before the actual breaking release and are currently the only place where migration can begin to happen. The new code can be simply reached via opt-in for migration with the pre-release syntax in the expecting ui-module's package.json.

Scenario

Stripes components v{{5.0.1}} has a breaking change (discussed an implemented) - work is placed in a release-v6.0.0 branch which can be versioned/tagged/released as 6.0.0-pre.1.
Stripes (v2.0) sets up its own next-release branch for v3.0 that pulls in 6.0.0-pre.1 explicitly. It gets versioned, tagged, released as 3.0.0-pre.1
FOLIO ui modules, anticipating the release of stripes 3.0 can explicitly set v3.0.0-pre.1 and pull in those features as soon as they wish for a migration branch.

Early exposure of new features is but one benefit of the pre-release process.
consider other potential applications:
@folio/stripes: "^3.0.0-lts.1" for long-term-supported versions
@folio/stripes: "^4.0.0-snapshot.1" for cutting-edge test-stable releases.

Next step after success of this process will be automation of this (though suggestions are great at this point)



 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

  • isn't the pre tag effectively the snapshot tag eg. we won't generate a pre release every commit, only explicitly?
  • why do we need an LTS tag? If we moved from 5.8.3 to 6.0.0 and later decide to release a security patch to 5.x from the lts branch, why can't that simply be 5.8.4?
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 ]

My concern is: will this break our CI system?

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 FOLIO-895 Open .

isn't the pre tag effectively the snapshot tag eg. we won't generate a pre release every commit, only explicitly?

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.

why do we need an LTS tag?

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.

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