"Max Bowsher" <maxb@ukf.net> writes:
> The problem is that it is presented to the requestor as " Found in
> version: " - so they tend to set it - but the fact that it has been
> found in a particular version doesn't *usually* mean that it is unique
> to that version. We do not have many versions simultaneously active,
> in which we independently fix bugs. Thus, having a version field
> attached to a bug doesn't really mean anything. Whatever version a bug
> is reported in, we generally only care whether it still exists in
> trunk or not.
>
> If anyone can define a useful purpose for the version field, I'd be
> happy to keep it. But at the moment, we aren't using it in any way,
> and it's just getting filled in with no guiding policy by the initial
> filer of the issues. So, either we need some sort of policy for what
> the version field actually means, or we should get rid of it. I don't
> see any useful piece of information we can track in a
> choose-one-option field, so I'm inclined to get rid of it.
>
> If someone *can* see a good use for it, then I'd be happy to keep it on.
Well put.
Personally, I can't come up with a policy useful enough to justify the
overhead of having the field. But maybe Brane can? (hint, hint)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 19:57:09 2005