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

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 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.

and 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).

Guys, should we change the interface version in the case of MODINVSTOR-248? In reality we are removing the ability to filter by itemId, so the interface conceptually has changed, even though this is not reflected in the RAML/JSON Schema?

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.

I prefer option 3. SNAPSHOT versions can change, they are indented to be used by developers only, and not by any potentially client.
Create a formal release if there is a client that needs them.
Jira has the "Fix Version/s" field for each issue where one can see what version change (bugfix/minor/major) this issue requires. Neither NEWS.md nor the -SNAPSHOT version in pom.xml reflect all changed made to master until a formal release is done.

I would appreciate your thoughts on this? Feel free to invite other interested people to participate as well.

My Personal Perspective

Option 3, merging without a version change (which occurred for ) leads to a snapshot version of the previous version containing the breaking change, which to me is IMO misleading and confusing for potentially client.

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.