Opened 4 years ago

Closed 4 years ago

# Add 1.2 to Trac Release ticket field

Reported by: Owned by: rjollos rjollos normal TracHacks normal otaku42, hasienda, osimons

### Description

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.

### comment:1 follow-up: ↓ 3 Changed 4 years ago by 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.

### comment:2 Changed 4 years ago by rjollos

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.

---

### comment:3 in reply to: ↑ 1 Changed 4 years ago by rjollos

• Status changed from new to assigned
• Trac Release 0.10 deleted

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.

[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 =


### comment:4 Changed 4 years ago by rjollos

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.

### comment:5 Changed 4 years ago by rjollos

• Resolution set to fixed
• Status changed from assigned to closed