On Nov 25, 2009, at 11:30 AM, Chris Hostetter wrote:
: > The point being: it's all been very informat up to now -- and
that's
: > probably for the best. "policies" should evolve over time based
on real
: > world situations that come up, and we're still in the process of
doing
: > that.
:
: Agreed, but now that the elephant has been identified in the room,
let's
: come up with a policy then. What are your thoughts on my proposal
(specified
: earlier in this thread)?
The elephant has been identified, and he's in the room, but he's in
the
far corner and he's not bothering anybody.
my personal preference (at the moment) is to leave things undefined
for
now ... i'd rather see us get to a point where we say "whoa, here is
an
actaul in the flesh cross roads where it feels wrong to release w/o
bumping the major version" and then to try and write down a policy
ahead
of time anticipating what that cross road is and how we we'll want
to deal
with it.
if it's unspecified, it can be specified later when it actaully
becomes an
issue -- if it's specified, then people will feel like we are
beholden to
the specification, even if it doesn't wind up making as much sense in
practice.
(yonik: you're anarchist ways clearly rubbed off on me at apachecon)
I agree with keeping it informal (for now)
I agree with Mark that yes, we should do what we can to make the best
choices about changes that affect compatibility. For sure.
The thing about the 1.5/1.9/2.0 question that makes me uncomfortable
is that it is applying the same 'official' rules from lucene to solr.
I am not sure how well that maps in practice. What would a 1.9
release mean in solr? (I don't really want an answer, I just don't
think it means the same thing in solr vs lucene)
Again, i have nothing against calling the next release 2.0 -- I just
think that 1.5 is also fine and keeps the door open for 2.0 to be a
more fundamental change in solr (that may or may not happen)
ryan
