On Tue, Dec 12, 2023, at 09:43, Volkan Yazıcı wrote: > I agree with Ralph's view. It is not just the *view* in itself that I find > appealing, but the (practically) deterministic nature of it. If one would > closely look at Robert's and/or Piotr's explanation of patch-vs-minor > strategy, it is pretty subjective,
I don't think Roberts's view was subjective; he gave some clear rules to follow. > aiming to eliminate. OTOH, Ralph's (or mine) is pretty straight forward: > > Will the next release *only* contain deprecations and/or bug fixes? Then it > is a patch release. For all other cases, it is a minor release. [Assuming > we all know and agree on what necessitates a major release.] Well, this is what is said here, right? - *MINOR version when you add functionality in a backward compatible manner* - *PATCH version when you make backward compatible bug fixes* Deprecations are no change in functionality but only a @deprecated tag. I assume this is why they are not listed specifically, and also don't see the need for it. > I propose sticking to this versioning scheme for all Logging Services > releases and documenting it. Objections? I am okay with following semver, as we already did. I am against re-documenting what is already documented in semver. We can mention that we use semver, but please don't write documents that interpret semver further. Are we trying to solve an actual problem? I have not seen a disagreement on a previous version number yet, or did I miss it in the flood of emails? Christian
