Ted makes a good point, but it's only valid IF people are looking that closely at the bug list and taking the time to make the proper inferences about the intentions of the developer team.
Isn't it much better to make those intentions plain by directly stating them in the roadmap document? Like "with the start of development on 1.2, the Struts Development team is targeting having releases substantially more frequently, which contain only one or two significant new features, along with some [* you can say whatever you want here -- "all reported", "all critical and above", etc] bug fixes". That way, you are not relying on Struts users to look through a set of bug reports and figure out somehow that the philosophy has shifted to having more frequent busses. Steve > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 5:09 PM > To: Struts Developers List > 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) > > -Ted. > > > 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]
