On 12/4/05, Ralph Goers <[EMAIL PROTECTED]> wrote: > Sylvain Wallez wrote: > > > To last for a long time, a company/community has to make sure it has > > some customers/users. The new features in 2.2, if you look at them are > > more about managing complexity than bringing real new stuff. Is it > > something that will bring lots of new users? I don't think so. > > > > So although we have to maintain the current code base, we also have to > > think about what should be our next offering. > > Well, of course you are right. But the problem is we haven't finished > 2.2 and you're talking 3.0. Let's get 2.2 out the door and then talk > about 3.0. >
I think it makes some sense to start talking about what a 3.0 might look like. Two main reason for that: First, it is good to always have a long term architectural direction in front of you. It is one of the ways to help keep the community focused on what they are doing now and where they want to go in thhe future. Second, it helps truly indicate that the 2.1 branch is really moving into maintenance mode. At this point, it wouldn't hurt the community to come to some agreement about what the fundamental requirements are for a 3.0. OTOH, discussion about implementation would seem premature until the 2.2 branch has been shown to not be able to support all the capabilities the community wants to implement. Perhaps an area on the Wiki to discuss straw man features and requirements for a 3.0 release would be a good thing? Basically, the 3.0 discussion could be used to keep track of features and capabilities the community agrees are good things, but for some reason (architectural, structural, lack of time) doesn't want to do in the 2.2 branch. Some of the 3.0 features might later migrate into a 2.x branch or they may never go anywhere, but the discussion itself helps to keep everyone focused on what is needed now vs. what could be done in the future... -- Peter Hunsberger
