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 Tue, 27 Apr 2010 18:03:33 GMT

: Big changes, that'd be destabilizing if attempted on the stable
: branch, would be done only on unstable (= trunk).
: More "normal" changes, which can still include deprecations/some back
: compat, would be done on the stable branch and unstable.
: By segregating the big changes away from stable we should be able to
: keep stronger back compat on stable.  We also save our resources not
: building costly back compat layers that, because of their complexity,
: bring their own problems.  Also, our release numbers are more
: "standard" -- the .0 release will have major changes (unlike today
: where is has no changes except removal of deprecations).

Ok .. I think i'm caught up.

My vote: +0

I like the idea changing our release/branch process so that every major 
release (ie: 4.0) results in he creation of two branches: one for bug fix 
release like we have now (ie: branch_4_0 where patches for releases 4.0.1 
and 4.0.2 would be committed) as well as new branch for minor releases 
along that major line (ie: branch_4 where patches for release in 4.1 and 
4.2 would be committed instead of doing minor releases off of hte trunk 
like we do now) with trunk now becoming the place where changes targeting 
hte next major release (ie: 5.0, 6.0, 7.0) can be commited.

My concern is that this proposal essentially requires that our current 
back compat "contract" be eliminated in favor of a looser "we'll document 
what's changed and try to provide migration tools" type policy.  What i 
worry about is that if we do this w/o agreeing on some "higher precident" 
guidelines on what exactly will be "ok" back-incompat changes to make 
between major release, and what is "not ok" to hcange because it 
introduces too big of a migration gap, then this could result in major 
versions that are so widely differnet hte community gets fractured, with a 
big chunk of users never upgrading from 4.X to 5.X because the API and 
index formats are too widely different and the migration process is too 
cumbersome (ahem: maven1 and maven2)

That said: I don't know that we can ever hash out where the "line which 
should not be crossed" is on compat changes w/o trying stuff and seeing 
what happens, and i don't personally have any better suggestions, so i'm 
certianly not going to stand in the way.


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

View raw message