James Carman schrieb:
On 2/20/08, Oliver Heger <[EMAIL PROTECTED]> wrote:
Niall Pemberton schrieb:
I'm +0 on this release because I like to review the actual artifacts
> that are going to be distributed. The distros IMO meet ASF release
> requirements but if I run command "mvn -Prc site assembly:assembly"
> then the binary distro created also includes the javadocs and also
> -sources.jar and -javadoc.jar. Which kind of makes the argument for
> reviewing actual artifacts.
>
> Niall
Same for me. The artifacts look good. Looking forward for the final
distributions.
So, are you guys saying that you want to vote on the actual files that
will be released? While I agree that is a good way to do it, that
doesn't go along with the directions for preparing/cutting a release
that we have on our site. According to the directions, I am to cut
the release candidates (with the -rc* version numbers in the pom)
until I get an affirmative vote (I believe three +1s are required and
right now I have one if I'm allowed to count mine). Then, I cut the
actual release (again by changing the pom.xml file to add in the real
version number for the release) and checksum, sign, and deploy it.
There is no vote again according to the directions.
So, do you guys want me to cut the actual release and let you vote on
that? Is that what you mean by "looking forward for the final
distributions"? If this is the case, shouldn't we update the
directions to let folks know? Maybe we should do [DISCUSS] threads on
the candidates until folks feel comfortable with them and then do a
[VOTE] thread? If something shows up after the discussions that
someone isn't comfortable with, we can always go back to cutting
candidates until the kinks are ironed out.
You are right, the release instructions seem to be outdated in this area.
It has become common practice to cut release candidates, tag them as
such in subversion, but set the version numbers to the actual release
version. (Typically you set the version, e.g. 1.0, in the pom, create
the distributions and the subversion tag for the rc, and then roll-back
the version number to the snapshot version, for the case that the vote
fails.)
So these artifacts look exactly like release artifacts. (To avoid
confusion, they are not announced in the public, but only on the dev list.)
Then if the vote passes, these artifacts can directly be deployed to the
maven repo, and the tag for the rc can be copied to the release tag.
Otherwise a new iteration is necessary.
Oliver
Oliver
>
> On Feb 19, 2008 11:31 PM, James Carman <[EMAIL PROTECTED]> wrote:
>> All,
>>
>> I have prepared a commons-proxy-1.0-rc2 release candidate. The
>> distribution files can be found at:
>>
>> http://people.apache.org/~jcarman/commons-proxy-1.0-rc2/
>>
>> and the site can be found at:
>>
>> http://people.apache.org/~jcarman/commons-proxy-1.0-rc2/site
>>
>> The SVN tag used to create the release can be found at:
>>
>> http://svn.apache.org/repos/asf/commons/proper/proxy/tags/proxy-1.0-rc2
>>
>> All issues brought up thus far with the first release candidate have
>> been addressed. Again, this is my first release (including signing),
>> so please review thoroughly (not that you normally don't).
>>
>> Thank you,
>>
>> James Carman
>
> ---------------------------------------------------------------------
> 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]
