[Bill, you definitely should do something with your email client, e.g. using plain text only, replying to your messages breaks indentation level (like the number of '>' preceding/according to the initial message)].
On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr <[email protected]> wrote: > > On Dec 24, 2016 07:57, "Jim Jagielski" <[email protected]> wrote: > [For example, here I had to add a '>' for Jim's original text to be associated with the above "Jim ... wrote:"] >> >> My point is that even having a 6 month minimal (and that >> is, IMO, widely optimistic and unrealistic) of "no new >> features for 2.4" means that we are basically giving people >> reasons to drop httpd. It would be a widely different story >> if (1) trunk was ready to release and (2) we "committed" to >> releasing trunk quickly by focusing on low-hanging fruit >> which would make lives happier and better for our end-users. >> As I said, my fear is that we will not be able to "control" >> ourselves in limiting what is in 2.6, which will push the >> actual release far past the point where it is even relevant. > > Well as breaking changes go, changing URI to remain an encoded value and to > mandate module authors accept that req_rec is free threaded are breaking > changes. Not sure what the second point means, but preserving r->uri while also allowing to (and internally work with) an escaped form of the URI does not necessarily require an API change. (We could possibly have an opaque struct to manipulate the URI in its different forms and some helper(s) be compatible with the API changes' requirements, e.g. 2.4.x). Regarding the changes in configuration/behaviours, I don't think we should break things anyway (even accross majors, if possible/relevant of course), but rather provide options to have the one or the other behaviour (trunk having the now considered better behaviour, stable(s) the compatible one). My point is mainly that rather than focusing on version numbers, we probably should focus on: 1. what we have now (in trunk), and want to backport 2. what we don't have now, do it (the better wrt trunk), and go to 1. There's (almost) always a way to backport things, though it should not prevent us from doing the *necessary* changes (in trunk) for new improvements/features. Yet, first step is the "inventory" of what we have/want, each/all of us involved and constructive... Once this is done, let's see what is compatible or not (and if yes at which cost). If we are going to introduce incompatible features, let's do 3.x. If we are going to introduce many features at once, let's do 2.6.x (that's an announce/marketing "value", the user does not care about the version, (s)he does about the features). Otherwise let's continue improving trunk with 2.4.x. When we start implementing new features, first discuss/specify them, then implement, and see if it's compatible/backportable. For now, I don't see many (if any) incompatibilities in trunk (I surely don't have an exhaustive view), but many improvements to backport. Just my 2 cts... Regards, Yann.
