At 12:17 PM 11/22/2004, Justin Erenkrantz wrote: >I expect that as it stands right now most 2.0 modules will compile for 2.2 >with very minor (if any) changes. If we 'fix' 64-bit issues now, then that >means that their modules are going to undergo massive changes.
This I will attest to; porting to 2.2 for mod_aspdotnet, I encountered; - lost APR_BRIGADE_FOREACH - changed apr_pool_get_parent // apr_pool_parent_get and of course; link to libapr-1 / libaprutil-1. other than that, it was very clean. >That *will* affect the 2.2 uptake rate because our third parties will take a >lot of time to get their modules 64-bit clean (if they do at all). WHO CARES?!? That's on them. They can release bug fixes after bug fixes, or extend their list of tested/supported platforms as they get around to it. It's their problem. As it stands, WE will be in THEIR WAY with incorrect code in apr and httpd. At that point - they cannot address the problems until we release the next version minor (2.4 or 3.0). How unfair is that? >I still think this needs to be punted to 2.4. It's just *way* too big. Way too big for you to handle? Ok. Not asking you to develop, test or even review. >We'll also have to fix up all of httpd to be 64-bit clean. Not hard. >And, that's going to push 2.2 out even further. It's pointless arguing this aspect. Are we done with 2.2? If you want to vote on 2.2 - then vote on 2.2 - don't get in the way of other developers' progress with hand waving. That, I think, is the biggest lesson I took out of the httpd luncheons. >This is something we should take our time on - not try to rush out the door >and then have to go back and clean up because we rushed 2.2 (and APR 2.0) out >the door. No thanks. -- justin I could say the same about... ...nevermind. The lesson we learned, in a nutshell; When httpd 2.1-dev is mostly satisfactory, and we have an alpha that the community decides is ready to take to 2.2 - we fork. That fork gets stabilization improvements until it's beta, and finally GA quality. That GA release is titled 2.2.0. In the meantime, head becomes 2.3-dev. Once again, nobody is standing in the way of code fixes. They can be percolated down to the 2.2 branch (before or after 2.2.0 is blessed), and even all the way to the 2.0 branch. That requires more review, which it should so 'stable' branches don't destabilize.
