On Tue, Dec 30, 2014 at 8:38 AM, Gennadiy Rozental
Tim Blechmann
writes: b) 'blanked update messages' about anything that is done on an a develop branch, is useless for people who are submitting and/or watching tickets.
When one is expected to close the ticket? When fix is checked into devel or when fix is merges into master? Former is better for developer who can put the trac number into commit message and be done with it. Later is better for users, since there always will be some gap between commit and master merge. Yet it requires more effort/discipline from developer. I am not convinced which one is better. Maybe we can mark ticket as fixed at commit time, and make it merged/publically available when fix is merged to master. Can we tweak trac/svn hooks so that we introduce another state change?
You don't need to close the ticket to update it by: - stating in the comments that it is fixed in develop branch - changing the "milstone" to the next release version (as develop will be merged at some point) It is common practice in tickets usage and help users (like me) what should be fixed when or not. Regular releases of isolated features would be helpful too.