> The guidelines are fine with me and seem to make sense to get to an API
> stable next GA. It is good to have a list of 'To Do's' that needs to be done
> before next GA. That helps people looking for interesting and useful work to 
> spend their time :-).
> Once it is decided that the API is stable I guess we need
> to branch in order to avoid restraining further progress on trunk by 
> developers
> that want to change the API further in an incompatible way. This could still 
> be a '2.5.x' branch
> that morphs into a 2.6.x or 3.0.x branch later.
> My personal itch and use of my regrettably very limited amount of time these 
> days is
> on the current 2.4 and getting at least some of the features back into it
> (a little bit like Jim's approach). This has to do with my dayjob where it is 
> much easier
> to upgrade to 2.4.next than to a new GA version.
> But I see merit in getting more track on moving forward with current trunk to 
> something
> releasable. So go for the alpha tags and see if you get sufficient votes for 
> it and what
> the feedback of the broader community is. If it is valuable: Great. If not
> or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
> just stop
> due to lack of interest in the community.


Reply via email to