remove method/class OR change method arguments OR class size changes(C++) = major version bump add new method/class = minor version bump change/fix behavior without adding new method = patch
That should be the criteria for when to bump, at least according to semver as far as I understand. -Robert Middleton On Mon, Dec 11, 2023 at 11:15 AM Christian Grobmeier <grobme...@apache.org> wrote: > > Hi Volkan, > > I am not sure what you are proposing. > > On Mon, Dec 11, 2023, at 10:26, Volkan Yazıcı wrote: > > I propose embracing a common versioning scheme across all Logging Services > > projects; log4j, log4cxx, etc. > > As you already mentioned, except for some parts of Log4j 1, we are following > server already, and it looks like everybody knows about it. > > > match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will > > be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc. > > We have only 3.0.0 with the alpha label. You are not against it, I guess? > > > - *MAJOR version when you make incompatible API changes* > > - *MINOR version when you add functionality in a backward compatible > > manner* > > - *PATCH version when you make backward compatible bug fixes* > > > > We mostly have a problem whether the next release needs a minor or patch > > version bump. I propose to refine the official semantics as follows: > > > > Are we making a release to *only* address a set of particular issues? That > > is, does the following hold? > > > > [next release] = [last release] + [fix1] + [fix2] + ... + [fixN] > > > > If so, this needs a patch version bump. Otherwise, this is a minor version > > bump. > > I assume with "issue" and "fix" you mean "bug fix". > > I don't understand what is the difference to what semver says. > When you add functionality, it's a minor. If you just add fixes, it's a patch. > Did I miss something that we are doing differently?
