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

Reply via email to