Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-1415

SPIKE: consider pre-release syntax for UI module snapshots

    XMLWordPrintable

    Details

    • Template:
    • Sprint:
      CP: ready for planning
    • Story Points:
      5
    • Development Team:
      Core: Platform

      Description

      This ticket is being creating because I don't want John Malconian's suggestion in FOLIO-1344 get get overlooked:

      I'm thinking that the way we version UI components in the CI needs to change. It doesn't make any sense to version a component in testing as v1.2.3000123 and then release v1.3.0. It would make more sense for a developer to version the component in Github as something like 1.3.0-SNAPSHOT before development for that sprint or feature branch begins - similar to the process the backend Maven developers use - The CI can then iteratively append build numbers to that i.e 1.3.0-SNAPSHOT.1 until the release is actually made for 1.3.0 or whatever. I know that there are some limitations to how NPM dependency resolution occurs with snapshot releases, but they may work in our favor with this model - TBD.

      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 (STRIPES-543) should alleviate this, by pointing the app/platform to a version/snapshot of the framework which takes care of the underlying dependencies.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                mattj Matt Jones
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases