esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Release 1.0-RC2 in Jira
Date Wed, 24 Feb 2010 15:13:07 GMT
Hi all,

I must admit that I don't understand the approach here. I meant to
bring this up separately after the release, rather than as a negative
reaction, but I didn't move fast enough :-) In that light, please take
this as an alternative suggestion, based on how I understand the
inter-relation of releases and release candidates (RCs). I'm very very
open to considering other options, but I think we need to have the
discussion about how our release strategy works.

Here's my take:

Frozen JIRA release: 1.0
Release strategy: Frozen in a tag from trunk, then updates are made to
both tag and trunk and release candidates (1.0-RC1, 1.0-RC2) are cut
directly from the tag. If there are release-blocking issues with an
RC, then that ticket should go into the JIRA release that the RC was
cut from (1.0 in this case). Otherwise the issue should go into the
backlog. I realize we haven't been doing this for this release, but
effectively we have because the only activity on trunk have been
updates that are going into the release.

Working JIRA release (next release): 1.1?
Release strategy: We should have a discussion about what open JIRA
tickets should be targeted for this release, then move their "Fix
Release" to this release. If we decide we want to add features that
aren't set up as JIRA tickets, then we should have that discussion and
create tickets for them.

Backlog JIRA release: Backlog (or Unassigned)
Release strategy: All new issues (bugs and feature requests) should go
into this release in JIRA. Issues can be moved from the backlog into a
specific release, but it should be based on some sort of consensus, or
be open to veto. Developers should be encouraged to work on the issues
in the backlog as they are able, but I'd think the core team would
focus mostly on issues assigned to the next release (recognizing, of
course, that this is a classic open source "scratch your own itch"
situation and people will work on whatever they want). If an issue is
fixed while it is in the backlog, then the resolved ticket should be
moved into the current working release (1.1 in this case) so that it
is picked up in the release notes.



On Tue, Feb 23, 2010 at 11:54 PM, Richard Hirsch <> wrote:
> I created a new release in JIRA and started assigning issues to it.
> If anyone else has any features or bugs tro fix, then please add this
> info to JIRA
> D.

View raw message