Specification version bump for service info breaking changes

[tcezard]

I'd like yo get your group's opinion/guidance on what a sort of version bump should be applied to a GA4GH specification when we're applying breaking changes to the service-info part of the spec. Initially we thought it should get a major version bump but considering that the underlying specs might not change drastically, it seems overkill.

Any thought ?

[jb-adams]

As far as I'm aware, service info uses semantic versioning, which requires a major version bump for incompatible API changes, even if they are small.

If refget is bumping up to 2.0, this might also require a GA4GH review process, as it's outlined in our standards development process that major versions require a review. If the changes to the API are breaking but small, I can't imagine the review process taking long compared to an entirely new product.

@susanfairley can you comment?

[susanfairley]

My understanding is: breaking change = major version change = review. However, if the change is small, that should be highlighted going into review and I'd expect a swift and simple review as a result (unless it is a small change with major consequences). If the review isn't straightforward in the case of a relatively low impact and small change, then I'd be concerned that we're getting something wrong.

On a more practical level, I think major version change is the right call as it raises the profile of what is an (admittedly minor) change of behaviour that would create an incompatibility. Presumably, this is a change being made for a good reason, so this is a good way to share that with adopters and make people aware that an improved version of the spec is available.