On Thu, Nov 26, 2009 at 5:55 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > Niall Pemberton 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. > > You mean 1.3 above, right?
Yes sorry - I gave this a quick try here: http://svn.apache.org/viewvc/commons/proper/dbcp/branches/TEST_DBCP_1_3_BRANCH/ Would need to do a bit more for a proper release - version no, release notes, site etc >> 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 > > So I guess we're back to where I started ;) Sorry :( - I'm just throwing out ideas, but feel free to ignore if you want > Do we change the groupId for 1.4? I am a little worried about > unintentional incompatible updates, otherwise. I think were OK compatibility wise - DBCP will have additional methods and require JDK 1.6 - but I generated a 1.3-SNAPSHOT from that branch and then did a 1.4-SNAPSHOT from trunk and the clirr reports look OK in the 1.4 version clirr reports: http://people.apache.org/~niallp/dbcp13/site/clirr-report.html http://people.apache.org/~niallp/dbcp14/site/clirr-report.html > Also, I assume we do > two release votes and two full distros, correct? Yes I think so. Just get the 1.4 version into a state where we thinks its ready to release then Tag DBCP 1.4 from trunk. The create a DBCP 1.3 Branch from the DBCP 1.4 tag and run the ant script to comment out the JDBC 4 methods + updates for 1.3 version. Then tag DBCP 1.3. Then we do the usual release stuff for both 1.3 and 1.4 versions. distros: http://people.apache.org/~niallp/dbcp13/ http://people.apache.org/~niallp/dbcp14/ > Thanks for the offer to help! np Niall > Phil > > > > >> >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
