thanks for the info, that’s good news with semver! definitely makes upgrade-decisions a lot easier.
do you have a detailed release strategy on when you’ll do releases? i.e. will you gather all breaking changes and release one major release per year with non-breaking minor releases in-between, or will you have a regular (e.g. monthly) release cadence for minor/major releases but only decide on which version to bump based on what has been merged (e.g. there could be two subsequent major releases or no major releases for a longer time, depending on what has been contributed)?
if you’re using semantic versioning i think something like this could work:
- patch releases (0.0.x): only support the latest & greatest. there’s no risk in upgrading (presuming test coverage & code reviews are good enough). there’ll never be a “patch of the patch” release (think 0.0.x.y)
- minor release (0.x.0): theoretically there should be no need to support older versions here, the same arguments from the patch release can be used: there are no breaking changes between minor releases, so upgrading to a newer minor release should not bring more risks. the perceived risks between different minor releases is however greater (esp. for some managers), but if semver is played strictly then this is no issue
- major release (x.0.0): obviously this comes with breaking changes, so upgrading from one major release to another incurs effort for the consumers (in the best case to ensure that none of the breaking changes affect them, in the worst case to adapt their applications). an overlap in support is needed here.
i see different user groups with different issues/requirements for support times:
- there will be some which won’t have an issue with running latest & greatest at most (i don’t want to say “all”) times, mainly companies which only run elasticsearch and do not expose elasticsearch to anyone outside.
- companies, which offer products based on elasticsearch but do not operate the product on their own (classical “deployed customer” approach from the point of view of these companies) will have limited control over when their customers will upgrade. if these companies package elasticsearch it is important for them to be able to ship fixes in a non-breaking manner so that the upgrade is localised, if they don’t package it, it is important for their customers to be able to install new fixes in a non-breaking manner
- companies which offer elasticsearch as SaaS: their customers make direct use of elasticsearch, thus any breaking changes which are not related to operations (which is handled by the SaaS provider) will affect them. thus i would presume that the customer needs to define which version they want to use (with semver: defining the major version might be enough) & coordinate the roll-out of the breaking changes (to be honest, i don’t know how the ES offering of AWS & co. looks like)
remember also, that for the latter two cases it takes some time for companies to incorporate new software versions (for non-breaking changes this should be fast: bump the version, run it through security checks, automated tests, etc. & release it; for breaking changes it is however more effort depending on what changed) and for their customers to adapt to it. the smaller the supported timeframe is, the more effort it will be and the less likely it is that they might want to use it.
so something similar to what elastic has been offering (Free and Open Search: The Creators of Elasticsearch, ELK & Kibana | Elastic), but aligned with semver would probably be good: i.e. support the major release x until the major release x+2 is out (presuming you have <= 1 major release per year).