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. >>> >>> 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
