At 04:47 PM 8/26/2005, Maxime Petazzoni wrote: >Hi, > >> This also means that most "new features" would wait for the "next >> stable" version to be released. If the "next stable" isn't a 3 year >> cycle like 2.0->2.2, I believe this could be acceptable. >> >> I believe that we should have more stable branches, more often. I >> believe that we should try to only backport bugfixes and security issues >> to these branches, and attempt to avoid adding many new features. > >+1. > >I'm kinda new as an ASF committer, and all this backport stuff >surprised me a lot. I keep thinking we are spoiling our efforts on >backporting, backporting, again and again. Why can't we just move on ? >2.0 made is time, and everybody is looking forward for the 2.2 release >to show up. > >Only minor fixes and security fixes should be backported. A new >version of a piece of code should be kept for the next release. That's >why we have releases, after all : to release new, better code :)
Well, simply because, in httpd-project land, each committer or project member dedicates their time to what they feel benefits the project, e.g., we each scratch our own itch. Some have no clue what's going to be in 2.2 and don't care, because their 'next big thing' is refactoring Apache to remove http protocol or the filesystem from 'core apache', or introduce true async operations. Those won't happen in 2.2, probably not even until 3.0. Some devote their interest to 1.3 and ongoing support, because that's what their infrastructure was built out on, or they are using libtool/autoconf unfriendly platforms. Some are keen to supporting current 2.0 users, knowing that 2.2 will solve many problems but introduce alot of wrinkles, as the users must rewrite their conf and htaccess files due to the module rearrangement and directive changes. And some (the loudest, right now) are busily preparing what is 2.1-dev for it's eventual (and hopefully quite soon) release as 2.2 GA. So just don't be surprised when a few folks begin some discussion of fixing a bug in 1.3 or chatting about async (while we won't be able to trust any modules to operate truly async without being rewritten or at least thoroughly reviewed.) The httpd project really donesn't have one-mind, one-voice, and this diversity is why httpd prospered, while so many other projects dissolved over the years. Bill
