[DBUTILS] Version numbering (was: Java version not specified in POM)
Good catch. :-( Uh, if dbutils 1.1 was compatible with java 1.3, and we want to depend on java 1.4 in the next version, do we have to call it dbutils 2.0? I assume not; I think we can still call it dbutils 1.2 even though we depend on java 1.4 now. Is that OK? Similarly, could/should we call the java5 version 1.3? That would certainly save time on branch management...? sebb wrote: The pom.xml does not specify a java source or target version, so defaults to 1.3 (from the parent pom) As far as I can tell, the component requires at least 1.4 so the POM needs to be updated. [IMO the compiler settings should never be delegated to the parent POM] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBUTILS] Version numbering (was: Java version not specified in POM)
I believe we can call it 1.2 - as long as it's API compatible then tis good. The Java5 version is more up for debate. If the API is no longer compatible, then we start to lean to 2.0. Especially as calling it 2.0 allows for more of an overhaul of API. There's also an argument that wants the package names changed for each major version. Hen On Sat, Mar 7, 2009 at 2:45 PM, Dan Fabulich d...@fabulich.com wrote: Good catch. :-( Uh, if dbutils 1.1 was compatible with java 1.3, and we want to depend on java 1.4 in the next version, do we have to call it dbutils 2.0? I assume not; I think we can still call it dbutils 1.2 even though we depend on java 1.4 now. Is that OK? Similarly, could/should we call the java5 version 1.3? That would certainly save time on branch management...? sebb wrote: The pom.xml does not specify a java source or target version, so defaults to 1.3 (from the parent pom) As far as I can tell, the component requires at least 1.4 so the POM needs to be updated. [IMO the compiler settings should never be delegated to the parent POM] - 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
Re: [DBUTILS] Version numbering (was: Java version not specified in POM)
Henri Yandell wrote: The Java5 version is more up for debate. If the API is no longer compatible, then we start to lean to 2.0. Especially as calling it 2.0 allows for more of an overhaul of API. The the API in the java5 branch is backward compatible; the generics and varargs are erased at compile time. Of course, the code has to be compiled with target=1.5, but on a Java 1.5 VM you could swap it in and not notice the difference. If that lets us call it dbutils 1.3 and avoid extra branching work, that'd be great. -Dan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBUTILS] Version numbering (was: Java version not specified in POM)
On Sat, Mar 7, 2009 at 10:26 PM, Dan Fabulich d...@fabulich.com wrote: The the API in the java5 branch is backward compatible; the generics and varargs are erased at compile time. Of course, the code has to be compiled with target=1.5, but on a Java 1.5 VM you could swap it in and not notice the difference. If that lets us call it dbutils 1.3 and avoid extra branching work, that'd be great. Calling it 2.0 (and thus changing the package name) does give you more freedom, too (remove some clutter, simplify the API, etc.). Let's not forget that. Of course, that could be done post-varargs/generics. I'm not completely familiar with the API, but usually when you introduce a varargs method, you're replacing an existing array method along with a one, two, and three-argument method. I don't think those sort of changes are backward compatible (existing code would have pointed at the two-argument method for instance). Again, I don't know that's the case, but just wanted to make sure. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
