commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] 2.0 release
Date Mon, 25 Jun 2012 02:35:48 GMT
On 6/24/12 3:29 PM, sebb wrote:
> On 24 June 2012 20:41, Phil Steitz <phil.steitz@gmail.com> wrote:
>> On 6/24/12 12:00 PM, sebb wrote:
>>> On 24 June 2012 15:41, Phil Steitz <phil.steitz@gmail.com> 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 <phil.steitz@gmail.com>
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 POOL-217
>>>>>>>>>>> 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 7
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> The Tomcat 7 release is almost done, so I should
be able to
>>>>>>>>>> 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
>>>>> http://commons.apache.org/releases/index.html 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

My problem with that is that I have to depend on setting fiddling
and good luck to ensure something like what I want to release ends
up in a location that I can point a VOTE to.  I don't get to review
the artifacts locally or control what manner of cruft gets pushed
out with them.
>
>> 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.

What the process Mark described will do.  Seems a good compromise.
>
>> 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:
>
> http://central.maven.org/maven2/commons-jexl/commons-jexl/
> http://central.maven.org/maven2/commons-lang/commons-lang/
> http://central.maven.org/maven2/commons-net/commons-net/
>
> 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.

That goes way back to the maven 1 days before maven repos were
controlled in any way and is a consequence of the "you can't delete
anything" policy from the ibiblio days.  Back in the early m1 days,
people (not necessarily even associated with Commons) pushed out and
depended on snapshots somewhat randomly.  We asked later if we could
eliminate them, but were told we could not.
>
> 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.

Well, I never had a problem doing it with simple scripts and would
trade the control and assured success for the minor inconvenience
any day.

Phil
>
>> 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: 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
>>
> ---------------------------------------------------------------------
> 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