incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petter√łe <yoji...@gmail.com>
Subject Re: Release 1.0-RC2 in Jira
Date Mon, 01 Mar 2010 00:22:05 GMT
Thanks for starting this discussion Ethan.
I have actually been doing some thinking around this as well, mostly because I felt that voting
for every RC and then the release itself might be a bit overkill. Release candidates should
be for testing purposes only. If we vote on a release candidate (like we just did), then that
RC will be the point-release.

I think your suggestion here is great and I am all for it:
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. 

- anne
 
On 25. feb. 2010, at 15.19, Ethan Jewett wrote:

> I'll just respond now, since I think we just have a misunderstanding.
> Again, this is just my opinion and understanding. I have been known to
> be wrong before. ;-)
> 
> On Wed, Feb 24, 2010 at 4:30 PM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>> Excellent points.....
>> 
>> On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <esjewett@gmail.com> 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.
> 
> What are we planning to call the current release we are working on? I
> think this is where we are misunderstanding each other.
> 
> I would not put the letters "RC" into an actual Apache release. In my
> mind, there is only one release. Release Candidates (RCs) are test
> releases that are floated to the group to enable thorough testing and
> review, but they are *not* Apache releases. (I welcome being corrected
> by mentors and people who know better than me here. :-)
> 
> I suggest that when the group actually votes to do the release with a
> given RC, that RC (exactly and without change) is released as whatever
> point-release we are attempting. (Bigger projects have release
> schedules and specific numbers of RCs before attempting the actual
> release, but I don't think we need to do that at this point.)
> 
> Because of this, I think the pom.xml of a release candidate should
> probably specify the final release version we are targeting, rather
> than an RC release version. That way we can just release the RC
> directly rather than having to do another release vote with an updated
> pom.xml.
> 
> I'd just go through with this release, but I think we need to get this
> straightened out for the future.
> 
>> 
>> 
>>> 
>>> 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.
> 
> I thought we were attempting to do release 1.0 right now. We had
> several discussions about what JIRA items were included in release 1.0
> and we ended up dropping the new UI from scope along with a bunch of
> other stuff. So yes, I think release 1.0 is pretty well defined.
> 
> Everything else, in my mind, should go into a subsequent release (not
> a subsequent RC - RCs are just test versions of a release, so an RC
> for the 1.0 release should not include any functionality not included
> in the 1.0 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.
>> 
>> 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.
> 
> We can name our next target release without having locked down scope.
> That's all I was suggesting with "1.1". Having the release number out
> there in JIRA allows us to use the JIRA tool to manage release scope.
> 
>> 
>>> 
>>> 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?
> 
> Yes, trunk (in my opinion) should track the most up to date code base.
> Trunk keeps going even when we have locked a release using a tag.
> Really big projects have to do all kinds of stuff with locking trunk
> or having multiple trunks for different major versions, but I don't
> think we have to worry about any of that at the moment.
> 
> Ethan


Mime
View raw message