commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [pool] 2.0 release
Date Sun, 24 Jun 2012 22:29:51 GMT
On 24 June 2012 20:41, Phil Steitz <> wrote:
> On 6/24/12 12:00 PM, sebb wrote:
>> On 24 June 2012 15:41, Phil Steitz <> wrote:
>>> On 6/24/12 7:12 AM, Oliver Heger wrote:
>>>> Am 24.06.2012 03:05, schrieb sebb:
>>>>> On 23 June 2012 23:00, Phil Steitz <> wrote:
>>>>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>>>> Looks like only the relatively trivial POOL-220 and
>>>>>>>>>> affect
>>>>>>>>>> 2.0.
>>>>>>>>> +1
>>>>>>>>>>    We need to resolve these and do some javadoc
and site
>>>>>>>>>> cleanup; but unless there are other things we want
to get
>>>>>>>>>> into 2.0,
>>>>>>>>>> I would like to move this toward a release.  I will
>>>>>>>>>> volunteer to RM
>>>>>>>>>> if no one else wants to.  Is there anything else
we need to do
>>>>>>>>>> code-wise to get this ready?
>>>>>>>>> I don't think so. I got most things cleaned up before
I became
>>>>>>>>> distracted (for far longer than I expected) by a Tomcat
>>>>>>>>> release.
>>>>>>>>> The Tomcat 7 release is almost done, so I should be able
>>>>>>>>> spend some
>>>>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>>>> The two open issues for 2.x have been fixed. That leaves one
>>>>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>>>>> as yet
>>>>>>> have a satisfactory explanation. I think the code is ready for
>>>>>>> a 2.0
>>>>>>> release. A lot of the supporting material isn't.
>>>>>> I will get to work on that.  Patches welcome, of course :)
>>>>>> I will also start testing with dbcp2 to make sure all is well.  Are
>>>>>> we reasonably confident that we will not need any further API
>>>>>> changes to pool2 for dbcp2?
>>>>>>>> Great.  If there are things I can help with or areas of
>>>>>>>> dicyness [1]
>>>>>>>> in need of extra testing, let me know.
>>>>>>> I don't think any one part is dicer than any other. Having the
>>>>>>> existing
>>>>>>> test suite has really helped.
>>>>>>> If I had to pick on something, it would be the improved
>>>>>>> concurrency.
>>>>>>> Since that is the new bit, that is where the current test cases
>>>>>>> may ber
>>>>>>> lacking.
>>>>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>>>>> leverage the new stats reporting.
>>>>>> One question for the list:  is it still possible to release commons
>>>>>> components "manually" to the maven repos - i.e., without using
>>>>>> Nexus
>>>>> No.
>>>>> The only way to the repo is via Nexus staging.
>>>> Does this mean that the instructions on
>>>> are outdated and do
>>>> not work any more?
>>> Yes, that's what that means, at least for the uploading to mvn repos
>>> bit, and unless we can find a creative way to circumvent nexus,
>>> there appears to be no way to generate the release artifacts
>>> packages locally, inspect them, and keep them on p.a.o for voting
>>> and release.  Unless we decide to separate the maven repo publishing
>>> step, which I may be inclined to do for [pool] 2.  The steps to get
>>> the real distro (source and binary tars and zips) to the mirrors
>>> should still work, modulo some pom hacking to work around plugin
>>> regressions.
>> Nexus does not prevent any of this; it is a staging repo.
> It does block what used to be a simple, controlled process
> 0) generate, test and sign artifacts locally
> 1) upload to p.a.o
> 2) vote
> 3) move to release locations

This is much what one does now, where:

1) use maven to deploy to staging repo

> Now you need to count on maven to "deploy" to the staging repo and
> then move things across the network somehow to /dist.
> Unless, as you point out below, you make the actual release
> artifacts first and then "publish" to maven central separately.

Not sure I follow that.

> Unfortunately, that ends up requiring two votes, because you can't
> just move stuff into the staging repo (unless there is some way to
> do that, which would be great).

No, it only requires one vote, which is on the artifacts in the staging repo.

>> Note that Maven does not know anything about Nexus; Maven deploys to
>> the staging area which happens to be managed by Nexus.
>> The non-Maven archives can either be deployed with the Maven jars to
>> Nexus, and then the vote held on the combined set of archives,
>> or the non-Maven archives can be deployed to a separate holding area.
>> If using a combined staging area, the non-Maven stuff needs to be
>> copied dist/ (and deleted from the staging area) before the Maven
>> stuff is released.
>> [I had hoped that Nexus could be tweaked to do this automatically but
>> this has not happened]
>> Nexus does not fundamentally change the release process, its main
>> benefit is that it makes it harder to publish Maven artifacts
>> accidentally, as happened a lot of times before it was introduced.
> Only once in Commons, IIRC, due to an RM not following the "manual"
> process and running with scissors using the release plugin.

Just done a quick check of 3 projects at random:

Have a look at those directories; I'm pretty sure no-one really voted
on release version "20030307.151331".

Looks like snapshot versions were somehow released as full versions.

It seems unlikely that version 1.0-RC1 was ever intended for release either.

>> Nexus also takes care of maintaining the Maven metadata, and ensuring
>> that the files are created in the correct directory.
> Trival and easy to verify as part of the release prep and vote.

This is not a process I would describe as trivial.

> Phil
>>> Phil
>>>> Oliver
>>>>>> or the release plugin?
>>>>> Yes.
>>>>> You don't need to use the release plugin.
>>>>> I never have used it, and I've been RM for Net and CP etc.
>>>>> Just need to use "mvn deploy" with the appropriate profile and
>>>>> flags.
>>>>>> Phil
>>>>>>> Mark
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> For additional commands, e-mail:
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message