Thanks a lot for all the answers, waiting for more people to chime in! What I personally like (at a very high level):
1) create a 2.6.x branch from 2.4.x and start backporting commits from trunk (with votes etc..), up to the point that we feel 2.6.0 GA is ready, then follow the regular release process. Christophe's tool for visualizing diffs between trunk and 2.4.x could be really handy and helpful. 2) Leave trunk as it is, and consider fixing the issues currently outstanding. 3) Use STATUS to decide what modules/code is to be deprecated. 4) Decide when 2.4.x should be considered EOLed in the future. 5) Decide how/when to bump minor versions in the future, so anybody adding/contributing code to httpd will have a very high level expectation of when some code can be released. IIRC during the past threads it was mentioned that a lot of people contributed with good code still sitting in trunk due to backporting issues to 2.4.x (breaking ABI etc..). It is not really fair and it surely drives away contributors that aim to work on major changes to httpd. Luca Il giorno mer 23 ott 2019 alle ore 10:40 Stefan Eissing <stefan.eiss...@greenbytes.de> ha scritto: > > Hi All, > > I agree with CJ here. > > As I said in the past, my idea would be to: > - trunk -> trunk-old, > - copy 2.4.x -> trunk > - any feature to bring from trunk-old to the new trunk needs a champion, e.g. > someone who does the work (porting and test cases) > > To some, that looks like we do not honour past work from people (that was one > of the arguments brought forward last time). But it is not only about honour > of devs, but also about the sweat and tears of the maintainers during 2.6.x > releases. If a feature does not find someone to merge from one branch to > another, how could we support this feature in a release? What do the 5-6 > people who handle 99% of all PRs think about this? > > As to the list of things to abandon from 2.4.x, we could handle those like > the backport voting in STATUS. > > Cheers, Stefan > > > Am 23.10.2019 um 10:18 schrieb Christophe JAILLET > > <christophe.jail...@wanadoo.fr>: > > > > Hi Luco, > > > > I've nothing against a 2.6.x branch. > > My only fear is things in trunk that is incomplete and or not enough > > reviewed. > > In other words, our backport mechanism with at least 3 votes is safeguard > > for me. > > > > My personal point of view is that 2.6.x should be built with backports from > > trunk, just as done actually for 2.4.x. > > But I know it is not the point of view of many others that consider that > > what is in trunk is (or should be) functional, reviewed and tested. > > Anyway, even if some things are less reviewed, alpha, beta and GA are there > > to give others the opportunity to test and report issues, so I is maybe not > > that bad to go this way, after all. > > > > > > If we want to go on the 2.6 way, maybe we could open some discussion: > > > > - should we deprecate or remove some 2.4.x functionalities or modules? > > (mod_imagemap, mod_cern_meta, maybe NetWare support which has really low > > activity, ...) > > > > - should we remove things in trunk that are incomplete or lack consensus: > > (this illustrate my fears above) > > - mod_serf and libserf support? : serf project looks mostly > > inactive nowadays, mod_sef have no documentation > > - pcre2 support? (comments in commits or code say that it is > > incomplete and that there is performance or memory management issues) > > - things listed in 2.4/STATUS: PATCHES/ISSUES THAT ARE STALLED > > > > - should we increase the APR minimum version and cleanup existing code > > accordingly? (i.e. switch from some ap_ to apr_ functions) > > > > - we could start to write a "new_features_2_6.html" in order to list new > > goodies and incompatibilities and changed behavior > > > > > > just my 2c. > > > > CJ > > > > Le 23/10/2019 à 08:28, Luca Toscano a écrit : > >> Not even a comment? :) > >> > >> Luca > >> > >> Il giorno dom 13 ott 2019 alle ore 20:58 Luca Toscano > >> <toscano.l...@gmail.com> ha scritto: > >>> Hi everybody, > >>> > >>> in trunk's STATUS there are a lot of suggestions about things to > >>> improve/change for 2.6.x. There have been discussions during the past > >>> couple of years about how/when/if to create a 2.6 release branch, but > >>> for a lot of reasons we didn't do any progress. Would it be something > >>> to consider for the next months? > >>> > >>> Luca > > > > >
