Morgan Delagrange wrote: > Unfortunately I agree with Rod about the API. We're > trying not to tear up track, but it's an unreleased > component nonetheless. Once it's released, it will > enter the normal cycle of major releases/minor > releases/bug fixes that are supposed to give good > choices of features vs. stability. Right now it's a > beta, and it should only take a majority decision to > make changes. Majority decision? What do you base that on? From http://jakarta.apache.org/site/decisions.html: All product changes to the currently active repository are subject to lazy consensus. An action requiring consensus approval must receive at least 3 binding +1 votes and no binding vetos. Dirk Verbeeck wrote: > > If this is the case I can only say that I'll then must fork the HttpClient > code, > I need a stable/working version... period. > If it can't be in the commons then in the slide cvs or otherwise a private > copy but an unstable version that can break code compatibility or even > functionality, that is something I do not want to work with. IMHO the concept of a commons is DOA unless external interfaces are viewed as contracts. For that reason, I would suggest that jakarta-commons is the place for the STABLE version. Those that wish to make speculative changes are free to fork, and may even consider using the sandbox to do so. Otherwise, we should view jakarta-commons as a noble experiment that failed. - Sam Ruby
