I'll preface this by saying I'm not much of a developer myself, but I use a number of major open source software packages, and follow their development models pretty closely.
I don't understand all this fighting about branching and development. I don't understand why Apache 2.0 has been released, and recommended for production use, if, as many seem to be saying, it isn't "feature-complete". Every other project I've ever seen doesn't do active development on a released branch. That's just NOT how to do things. Yet Apache 2.0's API is changing, it seems on a daily basis. If this is release software, why are you changing the API? Examples: mySQL - 3.23.xx is released. Bug-fixes only. 4.0 is now in beta - feature freeze, bug fixing for release. 4.1 is alpha, 5.0 is pre-alpha. Those are where development is going on, use at your own risk, back-porting major bug/security fixes to the released/stabilizing branches. FreeBSD - 4.7 is the current release. Minor development occurs on the -STABLE branch, which will lead to the release of 4.8, 4.9, etc, with a -CURRENT branch for bleeding edge, which will become 5.0. When 5.0 is released, -CURRENT (which may then become -STABLE, with -CURRENT being 6.0) will be developed for 5.1, 5.2, etc. FreeBSD "releases" never change after they're released - point releases are made if absolutely necessary (4.6.1 and 4.6.2, for example) and a security-patches-only CVS tag is available for each release. Perl - Releases are made on even numbers (5.6, 5.8) with development happening in the next odd number (currently 5.9) which will be released as 5.10. Changes within branches (5.6.1, 5.8.1, if/when they're made) are for vital fixes only, and extensively tested in previous versions before being released. All of these projects have their own problems. But at least their users can know that "FreeBSD 4.7" or "Perl 5.6" is going to be the same piece of software between 4.7.0 and 4.7.1 or 5.6.0 and 5.6.1, with only minor changes. That's not so with Apache 2.0. I don't see what's so hard here. Maybe 2.0 isn't "feature-complete" yet. But I think it's time to give up on 2.0 and start doing things right. Start developing full-time on 2.1. Make it available as development software, clearly marked as such. Get it feature-complete. Set goals. Then, when the time is right, release it as 2.2. While you're going, backport bug fixes to 2.0 if they become necessary. But don't make API changes. Don't change the heart of the software. Heck, you shouldn't even be making MAJOR API changes in 2.1 - PHP and Linux have both made that mistake at different times, and many people would never touch them again because of it. Apache is a de-facto standard. Don't wreck it by going around making changes willy-nilly mid-stream and alienating your users. Pick a development model that doesn't have people running software that doesn't even have functional helper applications as if it's release quality. I'm sorry, but a broken htpasswd binary is NOT acceptable in a GA release. If I'd read this list before I switched to Apache 2.0, I never would have made the change. I don't want to start a flamewar, and I know the first cry is going to be "then why don't /you/ coordinate it?!" Take my advice, or leave it. I don't have the time to coordinate a major software project, nor do I think I'm capable of doing it right - certainly I couldn't do it "perfectly", nor do I think anyone could. I just think it can be done better than the way it's being done here. That's my several dollars of opinion. Take or leave it, it's up to all of you. I just use the software :) And I know there are a lot of people out there who feel the same way I do. Tim Wilde -- Tim Wilde [EMAIL PROTECTED] Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/
