: and substitute either 3.2 or 4.0. Speaking of which, I think simply : assigning a fix-version for "3.2" implies that it will be for any future : release (including 4.0) and so I don't see there's a point in assigning both : of these fix-versions. There are rare exceptions to this and I am aware of : course that our dual-development branches implies having to make two : commits.
No ... that's not really true at all: A bug might only exist on the 3x branch, in which case saying the fix was commited for the 3.2 release doesn't say anything about 4x releases at all; A bug might exist in 3.1 and 4.0 but require completley different patches to fix it; Once 4.0 comes out, it will be entirely possible for a feature to be commited to 4x and backported to 3x such that it's in release 4.6 and 3.10 but does not exist in 4.0-4.5; etc.... I think it's definitley important to track exactly what version on *every* branch an issue is commited in. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
