On Tue, 4 Feb 2003, Ted Husted wrote:
> Date: Tue, 04 Feb 2003 20:09:11 -0500 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Re: exit strategy was Plans for the upcoming 2/14 soft deadline > > My concern with a omnibus "1.2" bucket is that it will clearly have over > a 100 items in it already. I would hesitate to start marking everything > that qualifies as "backwards compatible" for 1.2 without qualification. > > Personally, I am ready to start marking choice items for the next > iteration after 1.1, which I presume is 1.2. > > I do believe that we should also be able to assign items to ourselves > for the next iteration after that. > > I would agree that after two iterations, things start to get hazy, but I > think we should be able to think in at least those terms. > > By thinking two iterations ahead, we encourage the idea that the next > bus will be along in a minute, and you don't have to crowd everyone into > this one =:0) > Earlier, we had agreed on using the version numbering and release strategy that httpd and Tomcat are using -- x.y.z milestones would be released fairly often (your idea of monthly sounds fine to me), without any implied "quality" metric -- then, they'd get voted on as being alpha, beta, general release, or broken. If we go that way, we can certainly start creating the 1.2.1, 1.2.2 milestones -- but I would still suggest we categorize all the existing LATER entries as either "1.2 Family" or "2.0 Family" first. Such a designation is NOT an express or implied promise to actually do something -- only a general grouping. When a committer volunteers to actually implement one of these tickets in a particular milestone release, he'd both assign the ticket to himself AND update the milestone to the specific one (1.2.1, 1.2.2, whiatever) that its planned to be finished for. So, I will go ahead and create 1.2.x milestones for the first few ... although I think it's still too early to talk about any specific 2.0.x milestones at this point. Does that sound like a reasonable strategy? If so, it should be codified in our process documentation so that we can point at it. > -Ted. > Craig > > Craig R. McClanahan wrote: > > I added milesontes for "1.1 Family", "1.2 Family", and "2.0 Family". When > > we start detailing out the 1.2 thinking, we can create milestones for > > specific 1.2.x releases. > > > > I don't see any viable way to separate what should be marked 1.2 from what > > would be marked 1.3 -- so, I suggest we say "anything fundamentally > > backwards compatible, perhaps with a little refactoring" goes in the 1.2 > > bucket, while "anything radically new or different" goes in the 2.0 > > family. > > > > Bugfixes against 1.1 releases can be marked with which 1.1.x release (if > > any) we plan to fix them in. As with 1.2.x, we can add those as we need > > them (I have karma on bugzilla). > > > > > >>David > >> > > > > > > Craig > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Ted Husted, > Struts in Action <http://husted.com/struts/book.html> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
