On Dec 4, 2015, at 4:51 AM, Adi Roiban
wrote: 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.
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