commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [all] m2 releases, common issues
Date Fri, 30 May 2008 18:27:49 GMT
On 30/05/2008, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> Dennis Lundberg a écrit :
>
> > Niall Pemberton wrote:
>  >> On Wed, May 28, 2008 at 10:35 PM, Dennis Lundberg <dennisl@apache.org>
>  >> 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).
See
>  >>>> 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: http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
>  >>>
>  >>>> 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
>  >> http://repo1.maven.org/maven2/commons-scxml/commons-scxml/0.8/commons-scxml-0.8.pom
>  >>
>  >
>  > 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.
>

Voting would also need to include the revision number - probably not a
bad idea anyway, as tags are sometimes recreated.

Maybe the Manifests should include the SVN revision number of the tag
used to build the release. [I'm doing this for JMeter builds]

>  This reminds me of the old story about the infamous version 2.96 of gcc.
>
>
>  Luc
>
>
>  >
>  > 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] http://jira.codehaus.org/browse/MSITE-25
>  >>>> [2] http://jira.codehaus.org/browse/MSTAGE-3
>  >>>>
>  >>>
>  >>> --
>  >>> Dennis Lundberg
>  >>>
>  >>> ---------------------------------------------------------------------
>  >>> 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