[Twisted-Python] Attaching the release number to a closed/merged ticket

[Adi Roiban]

Hi,

I would like to ask you if you think that is a good idea to have the
version of Twisted in which the changes associated with a ticket.

The use case would be: Someone search the net for something related to
Twisted (a bug or some feature) and the land to a Trac ticket. Just by
looking at the Trac ticket that person should see if the ticket is still in
work, is invalid or changes were made in release YY.NN

-------

My proposal for implementing this is:

Each release will have a new milestone with the same name called
'next-release'.

Once the changes for a ticket were merged the ticket is assigned to the
'next-release' milestone.

When release is done, the next-release is renamed to the release name and
all previous tickets will be auto-updated.

A new milestone called 'next-release' is created.

Invalid or duplicate tickets should not have the 'next-relesese' milestone.

-----------

Amber commented that using milestones for such a thing is not a good idea
and that we should use tags like: landed-in-15.5, landed-for-15.5 ... and
keep milestones like Python-3 unchanged.

I don't like tags as when a ticket is landed we don't know if next release
will be16.0 or 15.6.

We can use a 'next-release' tag and when a release is done, check all
tickets and update their tag.

--------

Please send your suggestions and comments.

Thanks!

[Glyph Lefkowitz]

Hi,
I would like to ask you if you think that is a good idea to have the version of Twisted in which the changes associated with a ticket.
The use case would be: Someone search the net for something related to Twisted (a bug or some feature) and the land to a Trac ticket. Just by looking at the Trac ticket that person should see if the ticket is still in work, is invalid or changes were made in release YY.NN
-------
Each release will have a new milestone with the same name called 'next-release'.
Once the changes for a ticket were merged the ticket is assigned to the 'next-release' milestone.
When release is done, the next-release is renamed to the release name and all previous tickets will be auto-updated.
A new milestone called 'next-release' is created.
Invalid or duplicate tickets should not have the 'next-relesese' milestone.
-----------
Amber commented that using milestones for such a thing is not a good idea and that we should use tags like: landed-in-15.5, landed-for-15.5 ... and keep milestones like Python-3 unchanged.
I don't like tags as when a ticket is landed we don't know if next release will be16.0 or 15.6.
We can use a 'next-release' tag and when a release is done, check all tickets and update their tag.
--------
Please send your suggestions and comments.

By "tags" do you mean "keywords"? If so, couldn't we just use the 'landed-in-next' keyword and then have a little script that replaced it with 'landed-in-15.6' at the time of the release?

-glyph

[Adi Roiban]

Post by Glyph Lefkowitz

Post by Adi Roiban
Hi,
Please send your suggestions and comments.

By "tags" do you mean "keywords"? If so, couldn't we just use the
'landed-in-next' keyword and then have a little script that replaced it
with 'landed-in-15.6' at the time of the release?
-glyph

Sorry... I was talking about 'keywords'. As long as the info is there, in
some form of another, I am fine with any implementation.

At this stage I just wanted to see if other people find this useful and
make sense to put some effort in implementing this... and I was trying to
make some notes regarding the effort required to implement this.

Thanks!

[Glyph Lefkowitz]

Post by Glyph Lefkowitz

Post by Adi Roiban
Hi,
Please send your suggestions and comments.

By "tags" do you mean "keywords"? If so, couldn't we just use the 'landed-in-next' keyword and then have a little script that replaced it with 'landed-in-15.6' at the time of the release?
-glyph
Sorry... I was talking about 'keywords'. As long as the info is there, in some form of another, I am fine with any implementation.
At this stage I just wanted to see if other people find this useful and make sense to put some effort in implementing this... and I was trying to make some notes regarding the effort required to implement this.
Thanks!

This would be super useful to me. I frequently answer stack overflow questions where I want to say what release of Twisted a particular bug was fixed in, and it's unfortunately hard to discover.

-glyph

[Tom Prince]

Post by Glyph Lefkowitz
I frequently answer stack overflow questions where I want to say what release of Twisted a particular bug was fixed in, and it's unfortunately hard to discover.

The attached script should get most of the versions for tickets. There
are a handful of tickets that get mis-categorized, though. This could
probably be used to back-fill fix versions, too.

[Tom Prince]

Post by Adi Roiban
Amber commented that using milestones for such a thing is not a good idea
and that we should use tags like: landed-in-15.5, landed-for-15.5 ... and
keep milestones like Python-3 unchanged.

I think rather than having a tag, it would make more sense to have a
custom field (http://trac.edgewall.org/wiki/TracTicketsCustomFields).
I do think using `next` as the version before a release makes sense. One
thing to note with that, is that tickets that land between branching and
a release shouldn't have the fix version updated.

Tom

[Adi Roiban]

Post by Tom Prince

Post by Adi Roiban
Amber commented that using milestones for such a thing is not a good idea
and that we should use tags like: landed-in-15.5, landed-for-15.5 ... and
keep milestones like Python-3 unchanged.

I think rather than having a tag, it would make more sense to have a
custom field (http://trac.edgewall.org/wiki/TracTicketsCustomFields).
I do think using `next` as the version before a release makes sense. One
thing to note with that, is that tickets that land between branching and
a release shouldn't have the fix version updated.

Thanks for the feedback.
Yes, we can have a tpcustom field.

Since Amber is the release manager I think that she should have the final
word.

Once we know that this is useful and there is a plan, I volunteer to
implement it.

For me, having the released version info in the Trac ticket is easier than
searching the NEWS file.

Thanks!