jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Release Management
Date Thu, 21 Dec 2006 21:17:40 GMT
Hi,

On 12/21/06, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
> do we have a development/release management paper that describes the
> usual dev tasks?

See my recent messages along those lines, "Jira guidelines" from Nov
29th and "Future versions in Jira" from Dec 18th.

> Q: What 'Fix Version' Should i choose when solving a bug?

See the emails I referred to above.

> Q: When i fix an issue, should i 'resolve' or 'close' it?

"Resolve" it. There are two reasons not to "Close" it directly, one
practical and one theoretical:

practical: When preparing a release I try to fix issue metadata to
make the Jira reports better. The metadata of a "Closed" issue can't
be edited, so I need to explicitly reopen and then re-resolve it to
make the metadata changes.

theoretical: When you fix an issue, you've "resolved" it for yourself,
but someone else might still have some problems with the fix. Only
when the fix goes out in an official release should it be considered
"closed". I'd even like to go as far as to mandate that "closed"
issues should never be reopened as the released code can no longer be
changed.

> Q: During Codefreeze, do i need to commit changes to trunk and frozen branch?

Committing to trunk is always OK.

Committing to a release branch is OK either if the release manager has
explicitly OK'd it or if the issue implicitly qualifies for the branch
as described in the "Fix Version" guidelines.

It's also always OK *not* to commit changes to a release branch, as
the release manager needs to in any case check for any pending changes
in trunk that should go to a release.

BR,

Jukka Zitting

Mime
View raw message