Yes, I think we need. This is widely used on other issue trackers and I feel like it is missing on Redmine/Chilli

How would it work in conjunction with versions (the way issues already can be assigned to versions I mean)?

Stefan Hållén wrote:

How would it work in conjunction with versions (the way issues already can be assigned to versions I mean)?

Stefan,

I assume we're talking about #215, so it would be used, lets say, to identify on which version a bug has been found. From the feature description:

When opening issues, reporters should be able to pick the version that the issue is reported in, by choosing from a list of released versions of the software. Developers should be able to tag this further as affecting multiple versions of the released product.

Stefan Hållén wrote:

How would it work in conjunction with versions (the way issues already can be assigned to versions I mean)?

You would be able to say "this issue happens in VersionX".

Eric Davis

Yeah, I get that part. I was just thinking about how it would (backend-wise) differ from how issues are assigned to versions.

I guess this would be completely separate, because the bug might occur in all 1.1.x versions, but not in 1.5.x, and you're still maintaining 1.1. So you'd want a new issue, relating to the 1.1.x version(s?) and belonging to the next 1.1 release?

Stefan Hållén wrote:

I guess this would be completely separate, because the bug might occur in all 1.1.x versions, but not in 1.5.x, and you're still maintaining 1.1. So you'd want a new issue, relating to the 1.1.x version(s?) and belonging to the next 1.1 release?

Yea I think so. So the select would be like:

Affected Version:
[ ] 1.0.0
[ ] 1.1.0
[X] 1.1.1
[X] 1.1.2
[X] 1.1.3
[X] 1.1.4
[X] 1.1.5
[ ] 2.0.0

This would tell us that the bug hasn't bee reported in 1.0.0, 1.1.0, or 2.0.0 (either it's not present or no one tested yet). Then we could fix it and set the Target Version to 1.1.6.

Eric Davis

Hm, maybe it could be a "affected versions" : "from" - "to" ?

In many projects, there are a lot of versions... :)

I'm only talking about the ChiliProject.org website itself, not an actual feature for the software.

Eric Davis

Having non-standard features in the issue tracker on chiliproject.org at least FEELS wrong to me :)

Stefan Hållén wrote:

Having non-standard features in the issue tracker on chiliproject.org at least FEELS wrong to me :)

I couldn't agree more. I really thought we were talking about the feature itself and not whether chilliproject would use it or not.

I do not see a problem in having non-standard features on cp.o, as long as they are easily available as plugin, say on cp's github account.

I think, this feature would be very useful for a software project oriented bug tracker, like the one on cp.o, but it is of limited use for other kinds of projects.

So I think we can discuss this feature for cp.o and we can discuss, whether this should be a core feature or a plugin. But I do not see, why these discussions would be interdependent.

Stefan Hållén wrote:

Having non-standard features in the issue tracker on chiliproject.org at least FEELS wrong to me :)

My proposal was to use a custom field, which is a standard feature. Sorry if I wasn't clear about it.

Eric Davis

Aha. Ah, well, sure :)