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 Thu, 25 Feb 2010 08:49:33 GMT
I'd suggest fixing major bugs (like in the RC1 branch and
putting new functionality in the trunk.


On Wed, Feb 24, 2010 at 10:30 PM, Richard Hirsch <> wrote:
> 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