> 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.
+1
