lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <>
Subject RE: discussion about release frequency.
Date Sat, 18 Sep 2010 11:59:43 GMT
> : Finally, as far as getting someone to do the work, I can certainly
> : volunteer to help in the following ways:
> : * being RM if you are ok with a non-maven release (until LUCENE-2268
> : is fixed, i am uncomfortable with maven)
> In the past i've argued that enough users care about maven we should
> really try to make sure we play nicely, but the more i think about it the
> less i think it should be part of the release process.

+1 - release managers shouldn't have to be in the love-Maven camp, which seems to be mighty
small here in Lucene/Solr dev-land.  User-land, however, is likely a very different story.

> the ASF releases source code.  When we vote on a release, tha's what we
> are voting on: source.  We may also distribute precompiled binary jars
> via the download mirrors, or via maven, but that's not what the release is
> about -- so let's get hte pom template files out of hte src tree, let's
> get the maven related tasks out of the build.xml file and treat publishing
> to maven as a seperate process that happens *after* the release.  We vote
> on the release, we release it, and then the folks that care about maven
> can publish the jars after the fact.

If what you mean is that maven artifact production tools should not be in the Lucene/Solr
source tree: -1000.  Requiring these to be hosted elsewhere would very likely kill Lucene/Solr
maven compatibility, and I don't think that's your intention.

Maven artifact production under Lucene's/Solr's Ant build suffers from the same problem as
releasing generally: lack of automation.  Too much manual intervention is required to keep
the .pom templates in sync, etc.  LUCENE-2268 would afford confidence in the produced artifacts,
but it would do nothing to address the current production process problems.


View raw message