> but that "update" doesn't need to be purely additive, it can be an >"edit" of an existing item in which case diffing the two versions of >CHANGES.txt will still tell you what you need to know.
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. We could also just merge down at the end as part of release. Or kind of run the middle ground, or do nothing. First option makes the most sense to me though. - Mark Chris Hostetter wrote: > : think thats important. It just seems the Changes log should read what > : changed from 1.3 or else its a little confusing. You could make another > : argument with so many on trunk - but in my mind, the only thing those > : going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - > : not follow the whole dev path as changes invalidate changes. Not a big > > it's equally important that people experimenting with trunk/nightlys have > an easy way to distibguish what's changed between the version their using > and the current version, so CHANGES.txt should be updated for every change > -- but that "update" doesn't need to be purely additive, it can be an > "edit" of an existing item in which case diffing the two versions of > CHANGES.txt will still tell you what you need to know. > > > > -Hoss > > -- - Mark http://www.lucidimagination.com
