It looks like the two issues revolve around the question if record separators should always be some combination of CR and LF or if they may be more exotic. I think that if someone made the call that commons-csv will not support exotic record separators, both issues could be closed very quickly. I'd support that call since I don't see any use cases for exotic record separators. After all, CSV is a specified format and while some tolerance is required to cover what has become a family of formats, I think that exotic record separators don't play a role here.
On Mon, Jun 30, 2014 at 8:58 AM, Gabriel Reid <gabriel.r...@gmail.com> wrote: > On Sun, Jun 29, 2014 at 3:50 PM, Benedikt Ritter <brit...@apache.org> wrote: >> >> Alpha, beta, or GA makes no difference if it's made public through maven >> central. As soon as something is available there, people will start to use >> it. This will lead to jar hell, when we decide/have to break BC between >> alpha/beta and GA. >> >> That said I'd just release trunk as 1.0, since nobody among us seems to >> have the ability/time to fix the last outstanding issue. > > +1 to releasing trunk. > > We had a similar discussion about this a couple of months ago. The > fact is that people are using commons-csv now, either by making their > own build or by pulling the commons-csv codebase directly into their > own codebase, and this will lead to the same jar hell issues when a > "real" first release comes out. I think that delaying the release > further, particularly for a couple of tickets that have been open for > over two years, will only make this problem worse. > > - Gabriel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
