lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: discussion about release frequency.
Date Sat, 18 Sep 2010 19:21:19 GMT
> I had not been faced with the scrofulous horror of Maven

Nice... Is this phrase copyrighted or can I use it extenuously without
paying royalties (eg, open sourced).  :)

In other words, I could not agree more.

On Sat, Sep 18, 2010 at 1:19 AM, Lance Norskog <> wrote:
> +1 on the ant-only policy. I've recently been futzing with Mahout and I had
> not been faced with the scrofulous horror of Maven. Please keep it out of
> the main source tree of solr. You can do whatever you want with the internal
> Apache build process.
> Chris Hostetter wrote:
>> My unscientific, off the cuff, sociological impression is that once we
>> moved forward with
>> the "multi-branch" development plan and created the 3x branch, a lot of
>> people who use to be the big proponents of regular releases got really
>> about the freedom involved in working on the trunk, and lost their
>> motivation to push for releases - because a big part of that motivation
>> came from the backcompat concerns and the need to churn out releasees
>> with deprecations so that future versions could move forward ith more
>> interesting APIs.  "trunk" turned into the new hot sexiness.
>> but like i said: that's just my unscientific impression.
>> : I think now that we have a "trunk" for unstable development, and a
>> : "3x" stable branch, that we should think about cutting releases from
>> : this branch much more often, for example every month or two.
>> I think that might be overly ambitious, particularly because we've never
>> really talked about how the release process for the 3x branch *should*
>> work (given the lucene/solr development merged) let alone start on those
>> changes to make it easy (that process doc that scares the crap out of you
>> is just for Lucene-Java, there's an equally scaray one for Solr)
>> I think it's going to take some work just on build/process before we can
>> get our first "merged" release from 3x.  Assuming we improve some
>> automation while we're at it, then i think it's feasible that we could
>> start doing releases off of it every couple of months.  it would remain
>> to be seen wether we sould *need* to release that often -- it will
>> depend on wether anything new gets committed there -- but it would
>> certianly be nice to be able to.
>> : 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)
>> maven is such a contentious issue -- people either don't give a shit
>> about it, or think it's the end of the world if the jars aren't there.
>> 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.
>> 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.
>> -Hoss
>> --
>>  ...  October 7-8, Boston
>>      ...  Stump The Chump!
>> ---------------------------------------------------------------------
>> 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