Hello Gabriel, thanks for you interest in commons-csv. Please see my comments inline.
2014-05-02 8:15 GMT+02:00 Gabriel Reid <gabriel.r...@gmail.com>: > Hi, > > I was wondering if there is currently a specific plan or list of > requirements to be fulfilled before the 1.0 of commons-csv is made. > > For me personally, as well as (I think) other users of commons-csv, it > would be very useful to have a release as soon as possible -- even if > it is only to streamline the building and releasing of maven-based > projects. Apache Phoenix is one such project that is waiting for > something that can be deemed a release. > > If there are open issues that are specifically standing in the way of > a release, I would be happy to assist in attempting to resolve them if > someone can point me in the right direction. > we are close to a release for a long time now. However we are still looking for a solution to CSV-35 [1] and CSV-58 [2]. There have been long discussions around this issues and to me it looks like there still is no solution. If you have a smart idea feel free to create a patch. > > On the other hand, if there are many (technical) issues standing in > the way of a 1.0 release, what about making a 0.1 release with the > current state of the code? This would satisfy the need of having a > released maven artifact for those who need it and are currently making > use of snapshot builds. > > At commons we are crazy about binary compatibility ;-) We're going through a lot a trouble to make sure you won't run into jar hell when using our components. This is why you can use commons lang 2.6 alongside commons lang 3.3.2 in the same class path. To achieve this, we change the maven coordinates as well as the package coordinates when we break binary compatibility. The problem with the kind of "pre releases" you're taking about is, that we would have to go through all this trouble if we encounter a problem with the pre released version that can not be fixed in a binary compatible way. So we would have: maven: org.apache.commons:commons-csv:0.1 package: org.apache.commons.csv Now fixing the issues identified in 1.0 would lead to: maven: org.apache.commons:commons-csv1:1.0 package: org.apache.commons.csv1 Or do we go directly to 2.0? The problem is, even if we declare this release as an alpha release or what ever, people will start using it. And all of a sudden you have commons-csv 0.1 in your class path through transitive dependencies but you really need 1.0 which isn't compatible. You're app has been broken by a rushed out release with an unstable API... > In any case, if there's anything I can do to assist in getting a > commons-csv release out the door in the short-term, please let me > know. > The only thing to get this out of the door is to find a solution to CSV-35 and CSV-58. Regards, Benedikt [1] https://issues.apache.org/jira/browse/CSV-35 [2] https://issues.apache.org/jira/browse/CSV-58 > > - Gabriel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
