lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: discussion about release frequency.
Date Tue, 21 Sep 2010 23:40:52 GMT

: > to be seen wether we sould *need* to release that often -- it will
: > depend on wether anything new gets committed there -- but it would
: 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,
: etc.
: do we *need* to release because of that? no. *should* we release? I think
: yes.

Agreed, my point was merely that even if we get to the point where we are 
capable fo releasing off the 3x breanch every month (because we have the 
process/tools down pat) that doesn't mean we should.  we should release 
when we have features that we think are worth releasing, and are stable 
enough to support moving forward along that major branch.

For example: we probably shouldn't bother having a release if the only 
thing commited to that branch since the previous release are to fix some 
typoes in javadocs, or because new tests were added -- those changes are 
good, and worth having, but too much proliferation of minor versions for 
things that don't impact the users can be distracting and confusion, and 
makes it hard to recognize when a release is worth upgrading too (it's a 
girl who cried wolf thing).

The other situation to ocnsider is when a feature is commited which works 
correctly, and has good tests and documentation, but people have 
questions/reservations about wether the API is really what we want -- just 
because the calender says it's time for the quarterly release, and the 
code works, doesn't mean we should just blindly release.  (and yes, i 
realize that for the 3x branch, these API decisions should probably be 
hashed out on trunk before the feature is backported to 3x ... it's not 
hte best example)

In any case, i'm really just trying to bring things back to the point i 
was getting at in my last mail: the decision to release should be made 
based on state of the code, not the calender; but it would be awesome if 
hte process was automated enough that we could release as often as we 
thought the state of the code warranted it.

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

No argument there ... in the past i think this was really a combination of 
(a) "concerns about API/back-compat" and (b) "the release process is such 
a nightmare let's get a few more features in before we release so we don't 
have to do it again too soon" ... the 3x branch makes (a) a smaller 
concern, if we can make (b) go away we can pretty much release whenever we 


--  ...  October 7-8, Boston      ...  Stump The Chump!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message