: And an observation: shouldn't everything currently in Resolved have a
: FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
: it's already committed to trunk, it's obviously planned to be fixed in
: 2.1, right?
not neccessarily ... if somethings in the trunk, you're saying it should
be included in a release eventually ... but that doesn't neccessarily need
ot be the 2.1 release ,it might be the 3.0 release ... Fieldable is a good
example of something where a significant API change was made, should that
really got in a 21 release? ... maybe, but it's not clear.
if something is marked FV 2.1 then that indicates that it *should* be in
2.1 if/when 2.1 is released ... no FV means there is no set opinion on
when it should be released.
: What about adding a Committed field? Looking at the docs, it should be
: possible. I'm actually more interested in that field then I am in FVs,
: if not simply because it's a lot less ambiguous and subjective. I don't
: need to know the release process to interpret it.
i think what you are describing is really waht the intended purpose of FV
is ... so that people browsing Jira can see "oh, my bug was reported
before and a fix was included in the 2.0.7 release as well as the 2.1.3,
and 2.5 releass. I'm currently using 2.0.1 so the simplest upgrade is to
2.0.7 ... if someone else is using 2.3.4 they would either need to upgrad
to 2.5, or port their patch to the 2.3.0 branch"
if we really want to track all of this infomation better, it would
probably make sense to use the FV the way you describe (an indication
as to what release new functionality / bug-fixes have been
commited to) and have new (optional) fields indicating what FV has been
used for in the past:
How significant is are the changes resulting from this issue?
A - major bug fix; no api changes; should be put into an X.Y.Z
releases ASAP
B - minor bug fix or new functionality; only backwards compatible api
changes, should be included in the next X.Y.0 release
C - major functionality change; significant API changes, requires a
new X.0 release.
Reports on A could drive the creation of point releases, Reports on B
could indicate what can be merged into release branches for minor revs,
Reports on C can tell us wether the next release from the trunk needs to
get a whole new version number to meet our compatibility policies.
...the default being "B" ... so only if you know your stuff is important
or might cause compatibility problems would you need to flag it.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
