esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Release 1.0-RC2 in Jira
Date Wed, 24 Feb 2010 21:30:39 GMT
Excellent points.....

On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <> wrote:
> 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.

I admit I created the new RC in JIRA without really thinking about
whether we want to continue working from the tagged branch or not.  I
have no problem working on the tagged branch. I'm assuming that most
activity will take place there. But do you really think that there
will be very much activity on the trunk?

At this point, I'm trying to keep things as easy / simple as possible.
I'm hoping that there won't be any need to commit any changes to the
RC1.  To be truthful, I'd rather make the code changes in RC2 and tell
people to use the newer RC. Once we get farther along and a variety of
customers are using ESME,  then things will be a different story.

> 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.

Is the release 1.0 really clearly defined that we can say what goes
there and what goes into 1.1.

> 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.

I don't know whether we really have a 1.1 yet. I'm assuming that most
everything will go towards the 1.0 release.  Maybe we need a JIRA tag
for 1.1.

> 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.

Agreed. That is why I started this thread - to get the conversation started.

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.

But where should developers commit their code from backlog issues? In
the trunk?

> Thoughts?
> Ethan
> 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