Phil, if you feel strongly about your concerns of incompatibility, then I say keep the current groupId for 1.3, and move forward with 1.4/2.0 in the new groupId. This way people who continue to use the old groupId will never get hit unexpectedly.
Paul On Thu, Nov 26, 2009 at 11:55 AM, Phil Steitz <[email protected]> wrote: > Niall Pemberton wrote: >> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton >> <[email protected]> wrote: >>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <[email protected]> wrote: >>>> Paul Benedict wrote: >>>>> Oops.. I meant minor version bumps ;-) >>>>> >>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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? >> >> 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 ;) > > Do we change the groupId for 1.4? I am a little worried about > unintentional incompatible updates, otherwise. Also, I assume we do > two release votes and two full distros, correct? > > Thanks for the offer to help! > > 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
