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