Add 1.2 to Trac Release ticket field

[Ryan J Ollos]

Work towards Trac 1.2 is currently proceeding, which will eventually involve deprecating of parts of the API. To be prepared, we should add 1.2 to the Trac Release field.

[osimons]

1.2? Where? As far as I know there is ​trac:browser:branches/1.0-stable and ​trac:browser:trunk is at 1.1dev. A (likely) 1.2 at some further stage in the future is no basis for reporting current issues IMHO.

Changing it to "1.1" however may make sense, reflecting current trunk. I see we don't have a 1.1 release?

BTW, on the subject: We should allow to set an empty version. Like for this ticket the field makes no sense. Prefix the custom ticket options with | in trac.ini to add an empty option that basically makes the field optional. In fact; I think the default could even be empty, so that users actually have to make a conscious decision when setting Trac version - instead of the countless issues from users defaulting to wrong version because they don't know better.

[Ryan J Ollos]

Well, 1.1 is effectively the same as 1.0dev in the last development iteration, or at least that is my understanding after reading ​t:roadmap. We had a discussion about this on IRC. Here is the content of that. Please let us know if you still disagree after reviewing:

---

(11:55:34) rjollos: hasienda: with the new versioning scheme for Trac, do think we should end up adding both 1.1 and 1.2 to the "Trac Release" field for tickets?

(11:57:01) hasienda: rjollos: I'd recommend to just add 1.2, since uneven numbers are meant to prepare the next even == stable ones IIRC

(11:59:24) rjollos: hasienda: I tend to agree regarding the 1.2 version, though it seems too early to add 1.2, and yet it might be a minor advantage to allow those running 1.1 to indicate the version when opening tickets. This is probably not too much of an issue yet since development has been slow following the 1.0 release, but it will eventually step up I'm sure, and we'll have users running the bleeding edge adn reporting against 1.1.x.

(12:00:28) hasienda: rjollos: so better add 1.2 sooner than later.

(12:01:25) hasienda: rjollos: I do expect a good number of issues getting raised i.e. as soon as the 0.11 db API is finally dropped in trunk

(12:01:38) hasienda: rjollos: and this is totally unrelated to Trac-1.0

(12:01:59) hasienda: rjollos: and I'd value to tag it correctly from day 1

(12:06:30) hasienda: rjollos: but hey, I'm not "chief in command", so this is a discussion after all - just my thoughts, and I'm happy to learn different views on the subject, np

(12:07:26) rjollos: hasienda: I think you are right. Hopefully most users understand enough to report issues encountered when running 1.1 against 1.2 in Trac-Hacks. Either way, we'll sort it on a case by case basis at least.

---

I had also added 1.1 with some further explanation.

[Ryan J Ollos]

Replying to osimons:

BTW, on the subject: We should allow to set an empty version. Like for this ticket the field makes no sense. Prefix the custom ticket options with | in trac.ini to add an empty option that basically makes the field optional. In fact; I think the default could even be empty, so that users actually have to make a conscious decision when setting Trac version - instead of the countless issues from users defaulting to wrong version because they don't know better.

Made the suggested change.

[ticket-custom]
release = select
release.label = Trac Release
release.options = |0.8|0.9|0.10|0.11|0.12|1.0|1.2
release.value =

[Ryan J Ollos]

Later on, it would be nice to have some non-strict ticket validation steps. If the user doesn't enter a version, add a message such as Please select the Trac version that you are reporting this defect against, or select cancel to ignore, before allowing the ticket to finally be submitted. Additions such as these need to be handled with care though, as I and probably everyone else has had frustrating experiences with web forms that want more information and prevent submission.