[FOLIO-1746] SPIKE: When should a major behavioural version be reflected in the implementation version? Created: 28/Jan/19 Updated: 25/Jan/23 Resolved: 25/Jan/23 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Marc Johnson | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | platform-backlog, potential-decision | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | CP: ready for planning | ||||||||||||||||||||
| Story Points: | 1 | ||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||
| Description |
|
Context Recently, a pull request was merged for
This change initially had a change to the major implementation version of the module from <version>14.1.0-SNAPSHOT</version> to <version>15.0.0-SNAPSHOT</version> in the pom.xml, however that was removed. (A similar issue occurred in the resolution of
The release procedures say:
Question When a major behavioural change is to be made to a module, when should the version change? Should it be within the pull request, prior to it via the next snapshot version of a formal release or afterwards in a separate pull request for a formal release? Example
Should we either:
If the situation is different and there is a bugfix/patch pull request Q and the last formal release was 14.0.0 when should the version 14.1.0-SNAPSHOT in the pom.xml changed to 14.0.1-SNAPSHOT or 14.0.1?
If I have missed available options, please do feel free to add them. Or ask questions. |
| Comments |
| Comment by Marc Johnson [ 28/Jan/19 ] |
|
My Personal Perspective Option 3, merging without a version change (which occurred for
Option 1, involves planning a formal release prior to merging the pull request requiring greater coordination. My preference is for option 2, as it does not exclude option 1 if we want to formally release prior to it, whilst also trying to make snapshot versions clear. |
| Comment by Marc Johnson [ 28/Jan/19 ] |
|
Jakub Skoczen Julian Ladisch Niels Erik Nielsen Adam Chandler Eric Valuk I would appreciate your thoughts on this? Feel free to invite other interested people to participate as well. |
| Comment by Julian Ladisch [ 28/Jan/19 ] |
|
I prefer option 3. SNAPSHOT versions can change, they are indented to be used by developers only, and not by any potentially client. |
| Comment by Jakub Skoczen [ 28/Jan/19 ] |
|
Marc Johnson Julian Ladisch Adam Dickmeiss Guys, should we change the interface version in the case of
In general, should we consider changing the interface version for intended major behavioural changes? I am assuming this would then happen on the PR and it can be a hint to the lead maintainer to also bump the major implementation version number. |
| Comment by Marc Johnson [ 28/Jan/19 ] |
|
Julian Ladisch Thanks for updating the description in this issue. Apologies for my initially negative reaction to those edits. I've attempted to answer the existing questions below. Given that the core platform team owns this decision and my significant bias I shall try to refrain from commenting further unless invited to do so. Implementation version Jakub Skoczen I'd prefer if we kept the specific mod-inventory-storage decision and the policy guidance conversations separate, although, that may not be as possible as I thought given the different opinions. From Julian Ladisch opinion above, I think he believe we should not change the implementation version until formal release (and presumably base this upon the closed issues in JIRA)? I have an obvious and clear bias in both the specific issue for mod-inventory-storage and in the general policy for updating the implementation version during a pull request (much like I also did for news during that conversation). As I believe it is allows people to use the github repository as a source of change information and better reflects expectations for snapshot artefacts. Julian Ladisch and Adam Dickmeiss have both helped me to realise that is at odds with potential merge conflicts, and the desire to keep pull requests version / change management agnostic, and might make applying changes to bug fix releases more involved. Interface version @jakub I believe this is a separate policy, though as you suggest, a major interface bump would effectively mean a major implementation version bump is also expected. From my recollection of previous conversations, we agreed that interface versions are effectively published by merging to master and therefore should be made within pull requests (and it means that we might move multiple minor versions within a single formal release). I think changing the interface version for behaviour not described within the interface itself is a challenging area with significant trade-offs (especially if we intend to support replaceability). I think making that decision depends upon what we include in the interface. If the CQL indexes supported are an implicit part of the interface, then yes, this would be a major interface version change too. If we do that, we need to manage that cascade through the various modules that use this interface (which I think we were intending to avoid). |