commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [csv] Release planning for commons-csv
Date Fri, 02 May 2014 07:41:03 GMT
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.reid@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message