2

I have a service that uses a package which is basically just a wrapper around an ElasticSearch index. I had to update the index as new data is added on a yearly basis. The source of the data needs to be added to the wrapper, which means releasing a new version. This does not at all change the expected behavior of the wrapper, it just enables querying the most recent data as well.

This got me thinking, since I would like to stick to the semantic versioning as closely as possible. It's certainly no major upgrade, and since the functionality is completely backwards compatible it's not even a minor upgrade. Marking it as a bugfix, however, also feels wrong.

Now I was wondering if anybody had any insight as to what the "correct" way of handling such a scenario would be. My gut tells me that the minor version would somehow be the way to go, but it somehow feels like compromising rather than "the way to go".

Cheers!

TomMP
  • 131
  • 1
    wait.. "The source of the data needs to be added to the wrapper" this seems wrong. surely its just config – Ewan Dec 20 '21 at 12:56
  • For me this question (as a lot of question related to SemVer) could/should be flagged as opinion based because everyone would handle that differently. But as some people said the real issue here is not the semVer as you might think but the fact that you modify the service in order to modify the configuration. – f222 Dec 20 '21 at 13:37

2 Answers2

6

This looks like you conflated software version management with configuration management. Intuitively, such things as data sources to select from should be part of the deployment configuration of the software, and thus should not affect the software version at all.

However, if adding a data source is handled by building a new version of the wrapper software, a patch version doesn't seem to be too inappropriate, as you're not releasing new functionality.

The authors of SemVer probably didn't consider a scenario as yours, as it really should be done using a configuration, so their wording focuses on patching, but if you must use this approach it seems to be the least ugly choice.

Hans-Martin Mosner
  • 16,609
  • 1
    I'm marking this as the answer because it makes the most sense to me. I didn't explain the entire use case and why this came to be the way it is, but I understand that there simply is no semantic versioning guideline for this scenario. Thanks! – TomMP Dec 20 '21 at 13:56
1

This sounds like it should be a major version update - it seems that in the previous version of the software a function call would return data relating to e.g. 2019. In the new version of the software the same function call will return data relating to 2020.

So the expected behaviour of the old version is not maintained in the new version, it's not backwards compatible and therefore should be marked as a major version update.

This encourages people consuming the package to choose explicitly which version they need based on which data they are interested in consuming, and not let a package management tool choose automatically for them and apply the update silently.

bdsl
  • 2,724