[UXPROD-2584] Improve release and versioning of stripes* modules - Part I Created: 16/Jul/20  Updated: 19/Oct/20  Resolved: 19/Oct/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2020

Type: New Feature Priority: P3
Reporter: Khalilah Gambrell Assignee: Khalilah Gambrell
Resolution: Done Votes: 0
Labels: NFR, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to STRIPES-625 Setting up peerDependency relationshi... Closed
Development Team: Stripes Force

 Description   

Background While introducing the stripes framework solved some issues, it created others. We still do not have a coherent development process and approach to versioning .

This feature will allocate development to focus on improving the release process and defining an approach for versioning.

Benefits

  • rolling a new release of stripes (framework) doesn't involve changing every single app (unless it's a major release then it should need to be supported explicitly)
  • apps can depend (in git) on releases of stripes libraries newer than provided by the current framework (perhaps via some dev framework with caret versions)
  • apps can depend (in git) on code before it is released (or, releases published in a way marked explicitly as unstable, eg. with an NPM tag)
  • all development can take place without using the CI npms
  • there is a way to build a yarn workspace such that apps will prefer to use your local checkout of a stripes library rather than pulling in a redundant copy

Generated at Fri Feb 09 00:25:10 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.