[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: |
|
||||||||
| Sprint: | |||||||||
| Story Points: | 1 | ||||||||
| Development Team: | Core: Platform | ||||||||
| Description |
|
NPM managed backend modules, like graphql currenlty have dev version numbers like `1.1.1000202` |
| 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 ] |
|
| 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
|
| 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
|
| 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. |