We are waiting on only one thing for APR 1.0, the full set of versioning API functions. I don't know where this stands, and I know Greg was full of ideas/designs. I'd like to see some feedback on this.
>That can't work. httpd 2.0 needs the ability to work against a stable release >of APR. Hence, the APR 1.0 vs. 2.0 breakout. You are assuming that httpd 2.0 will be as long-lived a version as httpd 1.3, but that isn't going to happen. httpd 1.3 must be a long-lived version, because of the major overhaul involved in creating httpd 2.0. httpd 2.2 should be a rapidly adopted version because deployed servers and 3rd party modules won't be nearly as hard to migrate as the 1.3 to 2.0 migration. Some oddball platforms still can't build httpd-2.0 while they can build 1.3, with the introduction of libtool. And their favorite modules still might not have an httpd-2.0 port, partly due to the 'moving target' of httpd-2.0 development. Yes, httpd-2.0 is/will be forever keyed to 0.9. We need to clear out all of the early design cruft going forward. Quickly, so that authors adopting the httpd-2.1 model have the right declarations and none of the historic and now dead macros or stubs. Because 0.9, for a while, will inherit the renaming going on for 1.0, any 1.0 code that doesn't use new features can still be compiled (but won't be binary compatible) with 0.9 and httpd-2.0. >>Committing the change was the breakage. It violated -our- >>versioning rules. With the holidays, many eyes had been distracted >>elsewhere, so now we are just playing catch-up to catch invalid >>commits. > >No, it wasn't. We've broken the API lots of times before in the 0.9.x series. > You just want to enforce backwards-compatibility on APR when it isn't ready >because a project that uses APR requires backwards-compatibility. Part of me >says, "Tough." httpd made a poor decision relying upon a library that wasn't >1.0 with fixed version rules. Quit it... we've been binary compatible for many successive httpd releases. In fact, the last binary breakage was the 'widening' of the error number ranges, and the poll change, which in hindsite I would have vetoed for later release in the APR 1.0. No matter, that's done and we're moving forwards. We've proven the 90/10 rule that few changes need to break binary compat. And we've tried to stick to it. These changes we are discussing are minor, gratuitous, and introduce breakage just for the sake of breaking compatibility. >IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, >call that API 1.0. Apply relevant fixes as needed (bumping versions based on >the version rules - i.e. filepath_encoding bumps the minor). Then, start on >APR 2.0 with removal of deprecated functions and we can change signatures as >we like. -- justin No, we agreed a long time ago that versioning must be complete and immutable before we call this APR 1.0. Versioning APIs and macros shouldn't be changed between 1.0, 2.0, 3.0 and so on, so let's take the time and get it right. Branch APR_0_9_BRANCH for maintenance alone, and move on with the final '1.0' rollout. We are close, I agree. But there is no reason for all of these deprecated 0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move onwards to 1.0 (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0, the two builds are just not binary compatible.) Because httpd-2.0 is trying to remain binary compatible, it needs to stay back on APR 0.9 for official binary releases. Bill
