: There's no sense in CHANGES being a 'rolling list', when someone looks : at 4.0 they should be able to see whats DIFFERENT aka what CHANGED : from the past release.
I agree completely, the disagreement is *which* past release the list should be relative to. I don't know how many more ways i can say it: I believe that the list of changes for 4.0 should be labled (and contain) "Changes since 3.0" -- because that is the most recent "past release" sith a common development history. When we only had a single trunk and the 3.0 release branch was forked from the same place as the 2.9 release branch it made sense to think of the 3.0 changes list as "Changes since 2.9" because they were genuine success of eachother -- any code in 2.9 was by definition in 3.0 unless it was modified/removed by somehting listed in the 3.0 changes. That is not going to be true for 3.3 and 4.0 (or 3.4 and 4.0, or 3.7 and 4.0 or whatever our last 3.x release is before 4.0). The list of changes for a release should always make it clear *exactly* what is differnet between that release and the previous release with common "lineage" of source code -- it may sound weird, but it's what i believe and it's consistent with how we've done bug fix releases in the past -- they've refered to changes since their "parent" release, not since the last calendar release. Since no one seems to agree with me on this, I've tried to let this go (twice!) by stating my position and conceeding that it's not concensus -- but if you keep reviving the argument, i'll happily keep restating my beliefs. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
