jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Release automation (Was: svn commit: r641291 - /jackrabbit/branches/1.4/jackrabbit-jcr-commons/pom.xml)
Date Thu, 27 Mar 2008 08:01:30 GMT

See also [1]. This is the documented process we use over in Felix: It is
based on a build profile (release) in the parent pom [2] (which is
different from the root/reactor pom, which is important and simplifies

This profile has two setups:
  * generate the signatures
  * build the source and binary artifacts

I think, this catches just about everything and enables automation by
allowing to perform a release build with just two commands : mvn
release:prepare and mvn release:perform.

Now, part of a release build process is tagging the project and raising
version numbers. I think it is very valuable that the release plugin
also automates this step (except for the pom.xml license header removal
if the <project> tag is not on a single line) as it is certainly error
prone and worth automation.


[1] http://felix.apache.org/site/release-management.html
[2] http://svn.apache.org/repos/asf/felix/trunk/pom/pom.xml

Am Mittwoch, den 26.03.2008, 22:53 +0200 schrieb Jukka Zitting:
> Hi,
> On Wed, Mar 26, 2008 at 10:01 PM, Felix Meschberger <fmeschbe@gmail.com> wrote:
> >  Am Mittwoch, den 26.03.2008, 16:29 +0200 schrieb Jukka Zitting:
> >  > One of the reasons why I prefer not to use the maven-release-plugin.
> >  > Not terribly bad IMHO, but not ideal either.
> >
> >  Hmm, this is a known issue with the maven-release-plugin: the <project>
> >  tag must be on a single line, otherwise this happens...
> ACK. I think we can live with this.
> >  On the other hand, if this is the sole issue with the
> >  maven-release-plugin, so what ? There is a known workaround. On the
> >  other hand the plugin takes a lot of manual work off our shoulders and
> >  therefore is worth considering.
> Perhaps it's just my prejudice, but one concern with
> maven-release-plugin is that it takes over the SCM interaction and
> commits stuff directly to svn. I'm much more fond of tools like
> svnmerge.py that just prepare a set of changes in the local copy and
> let the user review and explicitly commit those changes. Of course you
> can revert things in svn if the tool does something wrong, so perhaps
> I'm just being overly paranoid.
> Another issue is that maven-release-plugin only really cares about
> Maven, whereas our release process should primarily be producing the
> -src.jar package that simply contains the exact release sources as
> tagged in svn. We could let maven-release-plugin do the release work
> and then create the -src.jar from the produced tag, but that seems a
> bit backwards and requires extra work. The maven-release-plugin also
> doesn't support the concept of a release vote.
> So, while I'm all for increasing release automation, I'm not yet
> convinced that maven-release-plugin is the tool we should be using.
> But feel free to convince me otherwise. :-)
> BR,
> Jukka Zitting

View raw message