On Wed, Jul 10, 2002 at 11:19:31AM -0700, Brian Pane wrote: > From my perspective, the event that should cause us to branch for > a 2.1 or 3.0 release isn't "this code change is too drastic for 2.0" > but rather: "this new feature that's useful to customers is impossible > to build or maintain on top of the 2.0 framework." And hopefully it > will be a while before we get to that point: 2.0's design allows us > to make a *lot* of changes without requiring a rearchitecture of the > core server. > > I'd really like to see a roadmap that says something like: > > Remaining 2.0 maintenance releases: > - Incremental performance improvements > - Bug fixes > - New modules and MPMs as needed > > 2.1: > - "Sandbox" processes in which to run untrusted plug-in code safely > - Further refactoring of the core daemon to make it easier > to support non-HTTP protocols > > 3.0: > - New architecture for massive scalability
I disagree, but not strongly. The reason I don't like the idea of a strict roadmap of features is because it has the tendency to place restrictions on what people can work on, and that isn't The Apache Way. The ad-hoc posting of patches and acceptance of those units of work has a great benefit in our volunteer community. If the roadmap is simply a list of cool things we'd like to add, and where some of the developers think the project is going, then it can be encouraging for new development. As soon as it becomes a tool to ban features from being incorporated into the tree, it will discourage spontaneous volunteerism. I'd much rather see the roadmap as our collective brainstorm. In other words, we should just keep going, looking at one patch at a time, and as soon as someone takes the reigns and produces something revolutionary that we aren't quite ready to force onto our 2.0 users, then it may be time to think about a branch. -aaron
