I am +1 with Niall on two separate releases. On Thu, Nov 26, 2009 at 11:47 AM, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton > <niall.pember...@gmail.com> wrote: >> 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. > > P.S. I'm will to put the time in to do at least one of these releases > - e.g. if you do DBCP 1.4, then I'll branch and create the equivalent > DBCP 1.3 release > >> 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 > >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
