I think we should follow what major applications servers are doing here. Most require at least 21 and recommend 25. It seems like a good idea to do the same for wicket. I'm against pinning our releases on specific java versions upfront. IMHO we should just take them as they go and pick whatever suits our needs best.
Emond Op wo 9 sep 2026 om 13:37 schreef Andrea Del Bene <[email protected]>: > + 1 . Just one more doubt about Java support. Shall we stay "one step > beyond " Java LTS? i.e not use the very last LTS (now 25) but the > previous one (now 21) and upgrade to 25 when the next LTS is out (Java > 29 if I'm right) > > On Tue, Sep 8, 2026 at 9:59 PM Emond Papegaaij <[email protected]> > wrote: > > > > It seems we all agree on a new release schedule, so I propose to move > > forward. I'll draft a mail to be sent to the Wicket Users list (and I > think > > we should also include announce) to announce our change in releases. In > > short: > > * We will release 4 new versions soon (proposal: first week of October): > > 11.0.0, 10.11.0, 9.24.0 and 8.19.0. > > * For 8.x and 9.x, these will be the last releases, no more support after > > that. > > * 10.x will be our first LTS line, supported until 14 is released. > > * From now on, we release a new major version every 3 months, so the next > > will be in the first week of January. > > > > Any objections? > > > > Emond > > > > Op vr 4 sep 2026 om 09:08 schreef Vít Rozkovec <[email protected]>: > > > > > Hi, > > > having used wicket for around 15 years since 1.4 or so, can't even > > > remember, and managing multiple mission critical business projects for > > > multiple companies, I also agree with more frequent releases. > > > So far wicket updates and upgrades were usually smooth for us. I don't > > > have any bad memories regarding that. > > > > > > What I'd like to propose though is to bump version to 26 so it follows > > > year of release, like Ubuntu does. > > > Then you would have 26.0.0, 26.04.0, 26.08.0, 26.12.0, 27.0.0, etc. > > > which would follow release year/month. > > > You'd also know that x.0.x are LTS releases. > > > > > > With more frequent release schedule it would make things more clear, > imho. > > > > > > Just my 2c. > > > > > > Vit > > > > > > Dne 03. 09. 26 v 20:29 Martijn Dashorst napsal(a): > > > > On Thu, 3 Sep 2026 at 18:15, Emond Papegaaij <[email protected]> > > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> Today Martijn Dashorst, Matt Pavlovich, Jonathan Locke and I had a > short > > > >> call to discuss our ideas about a renewed release schedule. > > > > > > > > Great talk, we should do that more often. > > > > > > > > Just one clarification: > > > > > > > > One clarification I think we should make explicit: a non-LTS release > is > > > > supported only until the next major release. > > > > > > > > During that 3-month window, it can receive normal patch or minor > releases > > > > when needed. So 12 could get a 12.0.1 for a bugfix or a 12.1 for a > > > > compatible feature. > > > > > > > > Once 13.0 is released, 12 is EOL and will not receive any further > > > releases. > > > > > > > > LTS releases are the exception: they continue to receive the agreed > LTS > > > > support after newer majors are released. > > > > > > > > Also these releases are time boxed so regular and small. If > something is > > > > not ready, it goes into the next one. > > > > > > > > Martijn > > > > > > > > > > > > > > -- > Andrea Del Bene. > Apache Wicket committer. >
