Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development

[DM Smith <dm...@gmail.com>]

On 04/26/2010 02:43 PM, Chris Hostetter wrote:
> 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
> procedure.
>
> 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)
>    
As I understand it:
Your guess is correct.
The goal is to have future development not be encumbered by bw compat 
maintenance.
Trunk will not try to maintain backward compatibility. (As I see it 
there is no longer any point to Version in trunk.)
It probably won't have deprecations.
There will be no 3.9 release that differs from 4.0 only in deprecations 
removed.
Moving from 3.x to 4.0 will require users to be deliberate and careful.


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