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 > >
