commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [all] m2 releases, common issues
Date Fri, 30 May 2008 18:11:48 GMT
Dennis Lundberg a écrit :
> Niall Pemberton wrote:
>> On Wed, May 28, 2008 at 10:35 PM, Dennis Lundberg <>
>> wrote:
>>> Rahul Akolkar wrote:
>>>> Thought I'd make a list of m2 issues I encountered while releasing,
>>>> with the intent of saving time for others who may see similar
>>>> behavior(s):
>>>> 1) Site plugin doesn't pick up server configuration (if you need
>>>> <server>/<configuration> in the settings.xml for site deploys).
>>>> MSITE-25 [1]. Patches have been applied (thanks to dennisl), but fix
>>>> is unreleased.
>>> The fix for this is included in the upcoming site plugin 2.0-beta-7, see
>>> schedule:
>>>> 2) Stage plugin only allows for scp:// target repo URLs. See MSTAGE-3
>>>> [2]. Patch has been applied (thanks to brett), but fix is unreleased.
>>>> 3) Using JDK 1.4 and some m2.0.x versions leads to a 2.4.1 version
>>>> number for the assemblies (just source, IIRC). Fix is to either
>>>> hardcode version in assembly descriptor or use JDK 1.5 (obviously,
>>>> thats not the real fix, but I don't want to digress).
>>>> 4) Release plugin will rewrite the SCM URLs. I used one approach (of
>>>> using the RC tag here), but not everyone liked it.
>>> This is by design. How is this a problem for us? Is it a problem for
>>> RCs?
>> Pointing to the RC tag, rather than final tag for the release - e.g.
>> scxml 0.8
> Ah, I see. That's because the way we currently do releases isn't
> directly supported by the release plugin.
> So we either change the way we do releases. Instead of voting on stuff
> with an RC-tag in svn we'd vote on stuff with a release-tag. If the
> release faila the release tag is removed and is later recreated when all
> problems have been solved. If someone wants to have a special RC-tag,
> for the sake of history, that can be accomplished easily with a command
> line subversion remote copy. If we wanted to, we could turn that into a
> Maven plugin and attach it to the release cycle.

I don't really like this idea. All our discussions are public and the
staging repository is publicly available. This means versions with the
proper tag and proper signatures are available for download by anybody.
If someone grabs one such version and the vote fails, we will end up
with two different versions with the same tags, different contents and
good signatures. I'm sure this will lead to confusion one day.

This reminds me of the old story about the infamous version 2.96 of gcc.


> Or we create our own version of the release plugin or supply patches to
> the existing one adding options to do things "our way".
>> Niall
>>>> Ofcourse, this assumes that everyone has a basic m2 setup configured
>>>> to deploy to p.a.o etc. (if some of us don't have it, thats #0 in the
>>>> list above).
>>> I don't think that there is anything to setup, besides installing M2.
>>> But if
>>> there is, then we should document it on the commons site. Perhaps the
>>> settings.xml config brought up by Henri.
>>>> -Rahul
>>>> [1]
>>>> [2]
>>> -- 
>>> Dennis Lundberg
>>> ---------------------------------------------------------------------
>>> 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