Hi Jacopo,
I agree that we should make a decision on this.
As for the backport to the release branch 24.09 it should be taken into
account that this can have a bigger impact on custom projects based on
the stable branch.
Those projects might rely on a stable codebase while pulling security
fixes (we have many of them lately!) through a vendor import. They would
be forced to do the Jakarta migration in a short period of time.
We know from the problems with solr that it can be very difficult if
custom plugins have dependencies which are incompatible.
That said, let's proceed with a voting in the form you have proposed
already.
Thank you very much and best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 17.06.26 um 11:42 schrieb Jacopo Cappellato:
On Mon, May 25, 2026 at 11:04 AM Jacopo Cappellato <
[email protected]> wrote:
Hi Nicolas, all,
Yes, what you suggest is indeed a valid alternative: setting the
end-of-life date for the release24.09 branch sometime soon (before 10
months from now). If we take this route, we should move quickly, because we
will need to stabilize the new branch and be ready to publish a release
from it within about 10 months. [...]
I think we should make a decision on this: either set an end-of-life date
for release24.09 before March 2027, which could coincide with the
publication date of our first release from a new release branch, or
backport the Jakarta migration (and any other relevant changes) that would
allow us to continue using our external dependencies safely, i.e., relying
only on dependencies that are actively maintained.
In the past, we have accepted stale dependencies and published releases
based on them. I do not think this is still acceptable, given the higher
security standards expected of modern software products.
If we opt for the former option (i.e., setting an end-of-life date for
release24.09 before March 2027), we will need to decide when to create a
new release branch. If we want a longer stabilization process, we should
create it sooner rather than later (e.g., release26.06, release26.07, or
release26.08), then stabilize it for a few months and release it as soon as
it is ready, but no later than March 2027.
Alternatively, we could choose a shorter stabilization process (under the
assumption that trunk is already sufficiently stable). In that case, we
could create the release branch later (e.g., release26.09, release26.10, or
release26.11) and release it after only a few weeks of stabilization.
To summarize the available options and propose a simple voting model, we
could start a vote on the following alternatives (i.e., cast your +1 vote
near the option you like most):
* Do not create a release branch now (this implies that we do not set an
end-of-life date for release24.09 and that we accept backporting Jakarta
and similar changes to extend its lifetime).
* Create the release branch release26.06 (branch created in June;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.07 (branch created in July;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.08 (branch created in August;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.09 (branch created in September;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.10 (branch created in October;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.11 (branch created in November;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release26.12 (branch created in December;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release27.01 (branch created in January 2027;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
* Create the release branch release27.02 (branch created in February 2027;
stabilization period to be decided later through a separate vote; release
any time before March 2027).
What do you think? Unless there are concerns, I will start a vote using the
above format in a separate thread.
Thank you,
Jacopo
