Brett Porter wrote:
I disagree on JIRA issues - for making release notes and keeping track I
think it's best to have an issue whenever possible.
Having detailed release notes is surely a good point since it's the
easiest way for users to rate a new release in terms of benefits/risks
when updating. But I guess something like "Improved javadoc" is not that
interesting that it should popup in the release notes, i.e. Vincent's
general distinction between "Minor changes" and "Larger changes" makes
sense.
However, I feel the statement
jira.apt
* <<Minor changes>>, like bug fixes
is misleading. Of course there a "bug fixes" like correcting typos that
can go in without jiras but in general I call a bug fix a major change
that is going to impact users ("Jesus, they got that working, great!") ;-)
Hence I propose the following update:
* <<Minor changes>>, like code reformatting, documentation fixes, etc.
that aren't going to impact other users can be committed without much issue.
* <<Major changes>>, like bug fixes, API changes, significant
refactoring, and pretty much any change of more than 100 lines, should
have a JIRA ticket associated with it, or at least an email discussion.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
