lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Date Mon, 26 Apr 2010 18:43:52 GMT

I didn't follow the Version API relaxation thread (my fault: i thought it 
was focused solely on how we were dealing with o.a.l.Version and lots of 
smart people were talking in ernest so i left it to them to make smart 
choices) but looking at this proposal, I'm at a loss to understand how 
it's any differnet then what we do today: we have a trunk, we add lots of 
features, and we document when compatibility breaks (and as a result rev 
our version numbers accordingly) ... in contrast, we have the "release 
branches" where we backport changes that don't break compatibility.  the 
only distinction seems to be this sentence...

: The stable line of development (on a branch) will get
: non-back-compat-breaking changes, and will be released more often (as
: minor releases and possible also .Z bugfix releases).

...i don't know that anyone would say we release "more often" off of hte 
existing release branches, but that seems more an issue of practice then 

So I feel like i must be missunderstanidng the goal here.

My best guess: that what this is really suggesting is that "trunk" 
*always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0, 
etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1., 
4.2, etc...) happen on "more stable" branches off of the major version 
release branches (ie: branch_3_0 forks off trunk when 3.0 is release, 
branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)

If i'm wrong, then can someone please explain it to me in a concreate 
actionable way?  (ie: specific examples of actions people would take 
moving forward under this new procedure)


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

View raw message