Even though you probably all know, just for clarity our policy has been that every release is a patch release until it isn’t. That is, as soon as something other than a bug fix is added it becomes a minor release. Personally, I think this still makes sense as it avoids needing the extra branch. With the changelog hopefully it should be very easy to identify whether it is a patch vs minor release. Perhaps it could even be enforced via the changelog plugin, or one could do mvn changelog:set-version.
What I have not liked is our haphazard release schedule. I’d be fine with having scheduled releases anywhere between every 1 to 3 months. That said, until 3.x is GA I would like to have beta releases every 2 weeks. Ralph > On Dec 4, 2023, at 2:15 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > Since we have a fast and easy release process now and a release does > not require a free weekend any more, I think we should have a regular > release schedule. > > Unless something exceptional happens (e.g. big bug that renders > `log4j-jcl` unusable ;-) ), I would propose to: > > * have a patch release every month, > * have a minor release every quarter. > > I can do a 2.22.1 release during the week of December 18th. > > Regarding minor releases, I am not a big fan of them. I would prefer > to wait for more than a single small new feature to appear in the > code, before making a minor release. > > I am getting (professionally) old and hopefully wiser. I think users > eager for new features can wait, while most users want stability and > releases that are less prone to break. We could even designate a > popular minor release as LTS (e.g. 2.22.0) and work on three branches: > > * `main` for 3.x, > * `2.x` for the next minor release, > * `2.22.x` for the next patch release. > > Changes that are not invasive would be applied to all three, new > features to the first two, while breaking changes to the first one. > > What do you think? > > Piotr
