Depends on if changes supports trunk or releases I guess. I think it's
dangerous to start down that line with trunk myself. It's one of the
caveats trunk users endure - I don't consider them when I make changes
in a dev cycle. It's the same way I'm not leaving deprecated methods
for them. We have enough responsibilty with back compatible than to
give trunk any priority over released versions IMO.
A classic change file lists release changes - personally I think it's
awkward to buck that convention and expose the dev history of a
feature in a release changes.
- Mark
http://www.lucidimagination.com (mobile)
On Sep 8, 2009, at 8:05 PM, Chris Hostetter <hossman_luc...@fucit.org>
wrote:
: Thats how we have been attempting to handle it in Lucene -
: update the previous issue with credits and merge the change
: info. There are tricky situations - someone can get credit for
: a huge issue when they just found a minor bug much later -
: but that seems to fit in line with our generous credit model
: anyway - if you really want to know, go to the JIRA issues. If
: the same person found the bug and posted a patch before it
: went in, they would be on the credit line anyway. If they find
: it after release, they get a new bug fix credit.
... "eh" ....
If a big feature is added, and then someone fins/fixes a small bug
with it
later, i dont' see anything wrong with having two enteries in the
CHANGEs
about this ... likewise if a feature is added and then a a bunch of
extensions are made to it ... at a certain point if you keep
collapsing
things just because they are related you wind up with one long
paragraph
about how "lucene" changed between releases instead of a nice bulleted
list.
the big key i think is not having things that contradict ... if a
bullet
says we added XY&Z, but then a latter bullet says Z was removed and
replaced with Q, we should just remove Z from the first bullet ... but
that doesn't neccessarily mean Q needs to replace Z in that
bullet .. Q
can still be it's own bullet.
-Hoss
