On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > Paul Benedict wrote: >> Oops.. I meant minor version bumps ;-) >> >> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pbened...@apache.org> wrote: >>> Another option to consider is splitting the version numbers such as: >>> >>> JDBC3 --> org.commons.apache.commons-dbcp-1.3.0 >>> JDBC4 --> org.commons.apache.commons-dbcp-1.4.0 >>> >>> Unless you have expectations to continue supporting JDBC3 in the next >>> major release, I would seriously suggest a version bump. The typical >>> use case of major version bumps are incompatibilities. >>> >>> PS: You could also try splitting 1.3.0 / 1.3.5, but you would have to >>> bring in a 4 digit for patch releases -- to avoid 5 1.3.0 patches >>> incrementing to 1.3.5. > > Thanks, Paul. That is an interesting idea. Are you recommending > that we change the groupId for both versions? If not, we could end > up with unintentional "latest version" upgrades causing problems. > The numbering could also be a little misleading. > > What negatives do you see in > > org.apache.commons:dbcp:1.3 > commons-dbcp:commons-dbcp:1.3 > > We have not decided yet on whether we will maintain jdbc 3 support > in 2.0, though that is doubtful. > > One other thing to keep in mind is that there will almost certainly > be 1.3.x patch releases to follow for both jdbc3 and jdbc4 > > Phil >>> >>> Paul >>> >>> On Thu, Nov 26, 2009 at 10:12 AM, Phil Steitz <phil.ste...@gmail.com> wrote: >>>> Jörg Schaible wrote: >>>>> Hi Phil, >>>>> >>>>> Phil Steitz wrote at Donnerstag, 26. November 2009 15:20: >>>>> >>>>>> Jörg Schaible wrote: >>>>> [snip] >>>>> >>>>>>> OK, but then we should really think about "drop-in replacement" or not. >>>>>>> Basically we say that dbcp 1.3 with JDBC4 will not be backward >>>>>>> compatible. Then why don't we use the new artifactId for this and allow >>>>>>> 1.3 with JDBC3 to be a real drop-in replacement? If somebody works with >>>>>>> ranges, he might get the newer dbcp anyway and wondering about the >>>>>>> incompatibility later. >>>>>>> >>>>>>> Therefore we might better do: >>>>>>> >>>>>>> org.apache.commons:commons-dbcp4:1.3 >>>>>>> commons-dbcp:commons-dbcp:1.3 >>>>>> Thanks Jorg and Grzegorz. Really appreciate the feedback. It is >>>>>> important that we get this right, minimizing confusion / bad impact >>>>>> to maven users and making upgrades both safe and as easy as >>>>>> possible. I was thinking the same way as you, Jörg, on the groupId >>>>>> change for the jdbc4 version. >>>>> Note, that I also changed the artifactId "dbcp vs. dbcp4" ;-) >>>>> >>>>> However, thinking about it, I am not sure if this is necessary and we can >>>>> really keep the artifactId (your first plan). If somebody uses both >>>>> artifacts (by transitive deps), his project is broken anyway. We simply >>>>> have >>>>> to point out in the website and README, that there are really two >>>>> different >>>>> commons-dbcp-1.3.jar files. Or is it too much confusion? >>>> That worries ma a little bit, more for Ant than Maven users. >>>> Incompatible jars with the same name in the wild is asking for >>>> trouble (well, like the old days ;). >>>> >>>> Another option, given that we don't have to mess with relocation >>>> poms, is just to use org.apache.commons:dbcp:1.3 for the jdbc4 version.
I'm starting to think it would be better to release two versions - DBCP 1.3 - compatible with JDBC3 and JDK 1.4 - DBCP 1.4 - compatible with JDBC4 and JDK 1.6 Use the same source, just change the version number, target JDK and comment/uncomment the JDBC_4 markers. Wouldn't this be easier in the end? When you're ready to release DBCP 1.4, then create a branch, run an ant task to comment the JDBC4 stuff, change the version & JDK target. Niall >>>> Phil >>>> >>>> >>>>>> I see this as killing two birds with >>>>>> one stone - getting us to the maven standard groupId moving forward >>>>>> and eliminating or at least making less likely the chance of users >>>>>> blowing up due to unintentional incompatible upgrades. >>>>> Yes. And we can avoid the tedious relocation POMs, because it is no >>>>> relocation. >>>>> >>>>>> Regarding Tomcat, Mark or someone else can chime in to confirm, but >>>>>> my understanding is that tomcat builds and repackages dbcp from >>>>>> source using Ant and as long as we keep trunk sources as they are, >>>>>> tomcat will be able to build all versions. >>>>> - Jörg >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
