Hi Jean,
This seems fine to me. Thanks for keeping JIRA honest.
Regards,
-Rick
Jean T. Anderson wrote:
Jean T. Anderson wrote:
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for
change notification.
The following page has been changed by MikeMatrigali:
http://wiki.apache.org/db-derby/TenTwoRelease
------------------------------------------------------------------------------
The following work flow can help ensure fixes get committed efficiently.
1. Pick a bug you want to fix and fix it in the trunk.
1. Submit your patch for the trunk.
- 1. Mark the issue resolved only after the fix is in the trunk. The fixin
fields should be marked as 10.2.1.0.
+ 1. Mark the issue resolved only after the fix is in the trunk, and has been
merged into the 10.2 branch. The fixin fields should be marked as 10.3 and
10.2.1.
on the docs I've been marking issues "resolved" after the last patch for
the issue has been committed to the trunk, then marking the issue as
closed when merged to 10.2.
Also, I've been noting the fix version as 10.3 then updating the fix
version to include 10.2 when merged.
bad idea? Should I change what I'm doing for docs?
thinking about this, here's what I'm actually doing:
1) After last patch for issue committed
+ uncheck patch available flag
+ set fixed version to 10.3
+ mark issue as resolved
2) After merge to 10.2 trunk
+ add 10.2 to fixed version
+ close issue (actually I haven't been closing, have let the owner or
doc writer close)
As I mentioned before, I'm happy to modify what I'm doing.
-jean
