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) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
