Hi Ate, Ate Douma wrote:
> On 10/10/2013 01:36 PM, Emmanuel Bourg wrote: >> Le 10/10/2013 13:26, Ate Douma a écrit : >> >>> Thoughts? >> >> A solution could be to change the package for every preview release. >> Something like: >> >> org.apache.commons.experimental.<componentname><number> >> >> So, for CSV we could release a 0.8 and 0.9 version under the packages: >> >> org.apache.commons.experimental.csv8 >> org.apache.commons.experimental.csv9 >> >> The package translation could probably be automated by the shade plugin, >> such that we keep developing with the org.apache.commons.csv package. > > While doing this might be somewhat automated, sure, I still would not > favor this. I think it tries to solve more of a perceived than an actual > problem. And it is not convenient for the experimental end-users either, > because they most definitely will HAVE to modify their code (manually). I am not strictly against milestones, but it requires a strict time frame for a final release. And I fear with all my experience gained in the years as Commons committer, that we will fail here badly. I was myself too often suddenly occupied with real life tasks. The problem in Commons is that our components are often widely used and the probability to depend transitively on different versions of the same Commons component is very high just by using a view different components of 3rd parties. The problem now with long lasting milestones is that for a final release the API might break again and suddenly you can no longer use safely those 3rd party components together anymore, just because one of it depends (transitively) on the milestone while all other can rely on the stable API. IMHO Emmanuel made an interesting suggestion, but I would not take it so far. Why not have a special package for any kind of alpha/beta/milestone release? For CSV we would then simply have: org.apache.commons.experimental.csv Advantage: Early adopters might already test the API without the requirement to 'update' the imports with every new milestone, but they are prepared to make API adjustments anyway and they are immediately remembered that they should not depend on the stuff in a release. Even if some stupid vendor uses now the experimental package for its own release, it is a lot easier afterwards to shade this package automatically for my own product without breaking any other stuff using the final API. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
