lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: discussion about release frequency.
Date Sat, 18 Sep 2010 12:53:16 GMT
On Fri, Sep 17, 2010 at 9:45 PM, Chris Hostetter

> 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.

Maybe, but deprecations shouldn't be the primary motivation for releasing

> 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.

I can't argue with this, I think the first release will be painful, but
thats exactly what I am proposing here, gearing ourselves up for more rapid
stable releases.

And as far as whether we *need* to release often, i'd like to start looking
at whether we *should*.
For a realistic example, Solr 3.x got autosuggest functionality. This isn't
really a disruptive thing, its not going to introduce a lot of deprecations,
do we *need* to release because of that? no. *should* we release? I think

To a lot of users, this is a major search engine feature, and they might
consider it more "major" than something we consider "major" like flexible
With stable releases, the user can put this feature into production more
easily because all the "sexy" stuff is in trunk, not causing them
This results in a faster feedback process for us, too.

I think we should try to avoid massive yearly releases with a ton of changes
at once.

Robert Muir

View raw message