Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports from trunk have maintained the 2.4.x ABI backwards compatibility.
So I would propose that if we do the below, which I am fine w/ BTW, that the 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI changes. Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, untested and wonky stuff that I would be somewhat worried about releasing... So that's why I like basing 2.6.x off of 2.4.x rather than trunk. FTR: Both APR and httpd have similar versioning guidelines (semver)... I don't see the attraction or need to revisit it. > On Oct 23, 2019, at 9:02 AM, Luca Toscano <toscano.l...@gmail.com> wrote: > > 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 >>> >>> >>
