commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging - take two
Date Fri, 27 Nov 2009 01:50:56 GMT
On Thu, Nov 26, 2009 at 5:55 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> Niall Pemberton wrote:
>> On Thu, Nov 26, 2009 at 5:46 PM, Niall Pemberton
>> <niall.pemberton@gmail.com> wrote:
>>> On Thu, Nov 26, 2009 at 4:57 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>> Paul Benedict wrote:
>>>>> Oops.. I meant minor version bumps ;-)
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:35 AM, Paul Benedict <pbenedict@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.steitz@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message