[FOLIO-574] ModuleDescriptor Implementation Version Created: 25/Apr/17  Updated: 12/Nov/18  Resolved: 15/May/17

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

Type: Task Priority: P3
Reporter: Adam Dickmeiss Assignee: Adam Dickmeiss
Resolution: Done Votes: 0
Labels: dublin, sprint13, sprint14
Remaining Estimate: Not Specified
Time Spent: 2 hours, 30 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to CIRC-4 Include module version in module ID f... Closed
relates to CIRCSTORE-6 Include module version in module ID f... Closed
relates to FOLIO-686 Blackbox: update roles to parse modul... Closed
relates to MODINV-6 Include module version in module ID f... Closed
relates to MODINVSTOR-5 Include module version in module ID f... Closed
relates to OKAPI-406 Enforce SemVer for module id Closed
relates to FOLIO-464 Design and implement module upgrade p... Closed
relates to MODCONF-4 include version string in the module ... Closed
relates to OKAPI-287 Document release procedure Closed
relates to OKAPI-366 ModuleDescriptor version handling SEMVER Closed
Sprint:

 Description   

So far, the semantics of id of the ModuleDescriptor has been vaguely described.



 Comments   
Comment by Adam Dickmeiss [ 25/Apr/17 ]

There no version in the ModuleDescriptor of Okapi except for interfaces. As far as Okapi proxy is concerned, should will load balance over a set of modules (deployed) with identical module IDs. If we want to upgrade a tenant to use a newer version of a module we must use another module ID. We could introduce an implementation version – say at same level as id and name, but it would complicate matters because, when we deploy we identify with module ID and that is no longer unique (for multiple versions). So I suggest we make the module ID unique by including a version in it. Using a format such as

  [^-]+-[0-9]+(.[0-9]+)*

that is : one or more characters followed by a dash followed by numerical parts with period as separator.

Perhaps we should allow more tricks than that. For example, the very annoying convention of -snapsnot in Maven makes the comparison somewhat difficult, because 1.3.0-snapshot is EARLIER than 1.3.0. Perhaps, just to make them identical we can allow suffix -SNAPSHOT to be "one less than".

ONe can also use serial number as used in DNS zones.. But the bottom line is that Okapi does not, normally, know what it means, but when we select a module from many , we would like them to be sorted somehow.

It is of course an extra burden to update this entry for a new release. Perhaps we could generate from the native package tool at hand, for example, by generating it from version in pom.xml.

Comment by Adam Dickmeiss [ 15/May/17 ]

There seem to be consensus about this

Comment by Adam Dickmeiss [ 20/Jun/17 ]

All related issues with this , eg CIRC-4 Closed , CIRCSTORE-6 Closed etc are unresolved.. Is this hard work or just forgotten?

Comment by Marc Johnson [ 20/Jun/17 ]

Adam Dickmeiss

I haven't forgotten about these, when I do a release I tend to ask John Malconian and Wayne Schneider if that release would be a good time to make this change (as I don't want it to stop these versions of the module from being deployed into our various black boxes or demo sites).

As far as I'm aware we don't yet have a module which has converted to these new scheme.

Comment by Wayne Schneider [ 20/Jun/17 ]

What is needed is a convention that all backend developers agree to follow. I would propose that the module id be the artifactId from the pom.xml with the version (also from the pom) – that way it's the same in both places, might be easier to maintain. So, for example `mod-users-12.0.1-SNAPSHOT`. In addition, the Docker image name generated by CI should match the artifactId. Finally, artifactIds should be a little more conventional – we have "mod-users" but "circulation-storage" – should the artifactId match the GitHub project name?

Adam Dickmeiss, Jakub Skoczen – can this go on the agenda for the 27 June backend roundup meeting, with John Malconian and I there to discuss, so that we can get an implementation plan in place for all 10 modules included in the current full-stack system?

Comment by John Malconian [ 21/Jun/17 ]

With regards to snapshot artifact versions I was intending to append a build number after -SNAPSHOT so that we actually know what iteration of a snapshot is deployed. For example, mod-users-12.0.1-SNAPSHOT.77. This is currently in place for UI modules but not backend modules. The build number suffix is not part of the POM obviously. So I don't know for sure how this impacts things. Module Descriptors are not treated as build artifacts, but perhaps they should be. If we do treat them as artifacts, we'd have to distribute those artifacts to some sort of other repository (and not alongside the project source. The advantage would be that the module IDs can be updated as part of an automated build process.

As far as creating build artifacts like Docker images with the same name specified by artifactId, we don't do this currently, but we can, if it helps. It will involve a lot of name changes to Docker repositories on Docker Hub and re-configuring build jobs in Jenkins to use the new convention. So we will need to coordinate such a change carefully. (I've been naming Docker images after the github project name.)

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