: > 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
want.
-Hoss
--
http://lucenerevolution.org/ ... October 7-8, Boston
http://bit.ly/stump-hoss ... Stump The Chump!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
