>From a user perspective, sometimes having releases too often leads to upgrade fatigue. Eventually it becomes easier to not upgrade, because so many things have changed in the interim that it becomes very annoying to attempt to upgrade things. For comparison, Ubuntu will do releases every 6 months, with LTS support on their releases every 2 years. This is reasonable, but may not be something enough people can commit to.
If things are properly versioned(API/ABI stable), then it shouldn't be an issue to do frequent upgrades. If things are stable though, is there a need to do a new release? Since users should only be interacting with the API, perhaps it makes sense to do core releases more often than API releases, but that would mean committing to allowing mismatched log4j-api and log4j-core versions. -Robert Middleton On Mon, Dec 4, 2023 at 5:04 PM Christian Grobmeier <grobme...@apache.org> wrote: > > Hi Piotr, > > I think scheduled releases that everybody can follow are great and your > proposal makes sense. > > Does this also mean we don't have that many "noise" emails from upgraded > dependency (releases)? > > I have come to realize in the past months that "inclusion" is most important, > and that would also mean slowing down things a bit so that everybody can > review. > > Thanks! > > Kind regards, > Christian > > > On Mon, Dec 4, 2023, at 22:15, Piotr P. Karwasz 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
