I'd suggest fixing major bugs (like http://issues.apache.org/jira/browse/ESME-162) in the RC1 branch and putting new functionality in the trunk.
D. On Wed, Feb 24, 2010 at 10:30 PM, Richard Hirsch <[email protected]> wrote: > Excellent points..... > > On Wed, Feb 24, 2010 at 4:13 PM, Ethan Jewett <[email protected]> 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 <[email protected]> >> 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 >>> >>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310850&fixfor=12314801 >>> >>> D. >>> >> >
