The current approach is designed to avoid predicting our release future as much as possible (plans do change sometimes :), while providing clear guidelines on how to categorize issues. What we're most interested in is whether the resolved issue should be released in the next mini release if we decide to do one, or if it should wait until the next minor release. Currently, I'm not aware of any 2.0 development going on (this is good since we don't have the branches set up for 2.0 yet :o), but issues that are just being tracked right now (ie, not being worked on) also can be marked for 'Next Major Release' or 'Next Minor Release' depending on whether the change affects BC or not, among other factors. Ultimately, I would highly recommend de-coupling our 'unreleased releases' from branch structure or current plans- it is a nightmare to update the issue tracker if either of those change, like when we decide to call the next release 1.5 instead of 1.1 ;), so this keeps us agile release-wise.
,Wil > -----Original Message----- > From: Nico Edtinger [mailto:[EMAIL PROTECTED] > Sent: Monday, January 28, 2008 3:00 PM > To: fw-general General > Subject: [fw-general] Issue Tracker Fix Versions > > Hi! > > As I as developer doesn't always know, which version is the next, I'm > a bit confused by the "next major version" or "next minor version". > Could we change that to something like "fixed in trunk"? If we've > fixes for a specific mini release we port them to a branch, thus we > know the version. But on the trunk it depends on the release > management. > > nico
