[FOLIO-2138] Version numbers of npm managed backend modules would cause dev versions to be considered later than release Created: 02/Jul/19  Updated: 02/Feb/21  Resolved: 07/Oct/20

Status: Closed
Project: FOLIO
Components: Continuous Integration
Affects versions: None
Fix versions: None

Type: Bug Priority: P3
Reporter: steve.osguthorpe Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-2092 use -alpha.NNN pre-release version sy... Blocked
Sprint:
Story Points: 1
Development Team: Core: Platform

 Description   

NPM managed backend modules, like graphql currenlty have dev version numbers like `1.1.1000202`
Given the number above, `1.1.1000202`, which is a development build towards `1.1.1`, when `1.1.1` is released, the dev version `1.1.1000202` would be considered more up to date as the version number is higher.



 Comments   
Comment by Wayne Schneider [ 02/Jul/19 ]

Since backend modules don't get pulled into a yarn platform frontend bundle, I think we do not have the same problem with npm's dependency resolution for prereleases – so perhaps for backend NodeJS modules, we can use the same prerelease versioning pattern that we use for Maven builds?

Comment by Zak Burke [ 03/Jul/19 ]

From Slack
Zak Burke

~ and ^ comparators DO NOT match pre-releases. This means we could be trouble when building a platform and apps ask for two different releases, e.g. "@folio/stripes": "^2.7.0" and "@folio/stripes": "^2.8.0-alpha.001". Apps depend on @folio/stripes only as a peer, to be provided by the platform, so this may just be a problem in workspaces where we’ll see an “unmet peer dependency” warning.

Wayne Schneider

This is exactly why we did it the way we do it now, IIRC.

I think the issues are related, but the one doesn't necessarily resolve the other?

Zak Burke

The issue is that Jenkins relabels dev-builds changing `3.1.0` to `3.1.1000202` rather than `3.1.0000202`.

If we moved to `-alpha.NNN` instead of artificially inflating the patch number, this would be resolved because `3.1.0-alpha.202` would be correctly recognized as a `pre-3.1.0` release (and to precede both `3.1.0` and `3.1.1`) whereas `3.1.1000202` appears to semver to follow `3.1.1`.

Wayne Schneider

I believe we discovered an issue with `.0NNNN` patch numbering.

Yes, see https://semver.org/#spec-item-2

Zak Burke

right, `.0NNN` is technically invalid, but `.1NNN` is higher than `.1` as noted here.

Wayne Schneider

Perhaps this conversation belongs on the issue...but I think ideally we would like to use prerelease versions for snapshots, as is conventional. The question is whether the package.json files as configured in platform-core, platform-complete, and stripes will pull them in.

Comment by Mike Taylor [ 03/Jul/19 ]

Wait wait wait, though. Isn't it the case that 1.1.1000202 is a development build towards 1.1.2, not 1.1.1?

Comment by steve.osguthorpe [ 03/Jul/19 ]

Mike Taylor Semantically speaking it is not a development version at all. And is the 1000202nd patch of version 1.1. And as 1000202 > 2, it would be selected over 1.1.2 when asking for latest 1.1

And no, I think if we wanted a dev version towards 1.1.2 (although that would be odd) it would be something like 1.1.2-alpha.1. We should never be developing releases towards patches like 1.1.2 as the last number is meant for fixes/optimizations to existing code. If we are adding any extra functionality that doesn't break the contracts put in place by the previously released version, then we should be developing towards 1.2 instead like 1.2.0-alpha.1.

Comment by Mike Taylor [ 03/Jul/19 ]

You're right, I've conflated the problem you're having here with an essentially unrelated practice in depending on not-yet-formally-released features in Stripes modules. Forget I said anything, and sort it out with Wayne and Zak

Comment by Jakub Skoczen [ 03/Jul/19 ]

Zak Burke John Malconian Wayne Schneider Are there any problems changing the CI versioning to use preRelease numbering?

Comment by John Malconian [ 03/Jul/19 ]

We need to spend more time on this to determine what is impacted before making a versioning change across the board to all NPM-based projects. The scope of this issue is just mod-grapql - a backend module.

Comment by Wayne Schneider [ 03/Jul/19 ]

Jakub Skoczen John Malconian see related issue FOLIO-2092 Blocked for discussion of prerelease versioning for frontend modules.

Comment by Mike Taylor [ 03/Jul/19 ]

Wayne Schneider IIRC you are including mod-graphql in at least some of your VM builds. Do you know what you're doing differently from steve.osguthorpe such that this works for you but not for him?

Comment by steve.osguthorpe [ 03/Jul/19 ]

Mike Taylor We are deploying modules within K8s which is very different to how the reference builds work ATM. Our build infrastructure assumes that versions that are full releases versions would be present in the release repository, 'folio' and not in the dev repository 'folioci'. When we can't find it we ignore it.

I was initially going to spend some time changing the process for how we consume modules, but I think the issue still stands as important. As presumably the `/install` and `/upgrade` enpoint in okapi would not pick up latest and new versions respectively.

Comment by Wayne Schneider [ 03/Jul/19 ]

steve.osguthorpe Mike Taylor – the reference builds pick up the "latest" version of mod-graphql based on sorting SemVer. Since we are interested in development builds, the high patch number works just fine, even though it is technically kind of wrong, or at least wrongish. When we build reference systems based on releases, we pin to specific versions, which is much less flexible (and less elegant) than what Steve is trying to do, I think. Using prerelease versioning would also allow Okapi to use the preRelease query parameter on the tenant install and upgrade endpoints to filter out prereleases when doing dependency resolution. So I think this is probably a good idea all around for mod-graphql.

Comment by Jakub Skoczen [ 03/Jul/19 ]

steve.osguthorpe Wayne Schneider David Crossley If this can wait, I would prefer we fix CI snapshot versioning for all NPM packages rather than specifically for mod-graphql. I think we could try to find some time for FOLIO-2092 Blocked

Comment by Mike Taylor [ 03/Jul/19 ]

Quite possibly the broader issue can wait. But I do need mod-graphql running in K-Int's ReShare back-up system. So if there's a simple workaround that can do that, can we please take the low road and just make it so?

Comment by Jakub Skoczen [ 04/Jul/19 ]

steve.osguthorpe Mike Taylor Guys, thanks for working around this on your end. We'll try address the CI versioning limitation next sprint, we're out of bandwidth for this one.

Comment by Jakub Skoczen [ 07/Oct/20 ]

John Malconian Closing because it's old, please re-open if still relevant.

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