Re: Future release schedule
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 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
Re: Future release schedule
>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 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
Re: Future release schedule
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
Future release schedule
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
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
github-actions[bot] closed pull request #3: Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
dependabot[bot] commented on PR #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3#issuecomment-1838104820 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
github-actions[bot] commented on PR #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3#issuecomment-1838104741 Changes are applied by CI in 3aeeafbbb80bba1542ed0a38261e79d6cb4d7b26 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0 [logging-log4j-jmx-gui]
dependabot[bot] opened a new pull request, #3: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/3 Bumps org.apache.logging.log4j:log4j-core from 2.21.1 to 2.22.0. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
