lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Norskog <goks...@gmail.com>
Subject Re: discussion about release frequency.
Date Sat, 18 Sep 2010 05:19:10 GMT
+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
>
> --
> http://lucenerevolution.org/  ...  October 7-8, Boston
> http://bit.ly/stump-hoss      ...  Stump The Chump!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>    

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message