Hello Jacopo, +1 about the vote
Many Thanks, Gil Le 17/06/26 11:42, Jacopo Cappellato a écrit : > 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
