[Twisted-Python] Attaching the release number to a closed/merged ticket
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!
On Dec 4, 2015, at 4:51 AM, Adi Roiban adi@roiban.ro 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
On 5 December 2015 at 02:17, Glyph Lefkowitz glyph@twistedmatrix.com wrote:
On Dec 4, 2015, at 4:51 AM, Adi Roiban adi@roiban.ro wrote:
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!
On Dec 6, 2015, at 8:04 AM, Adi Roiban adi@roiban.ro wrote:
On 5 December 2015 at 02:17, Glyph Lefkowitz <glyph@twistedmatrix.com mailto:glyph@twistedmatrix.com> wrote:
On Dec 4, 2015, at 4:51 AM, Adi Roiban <adi@roiban.ro mailto:adi@roiban.ro> wrote:
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
Glyph Lefkowitz glyph@twistedmatrix.com writes:
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.
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
On 5 December 2015 at 19:31, Tom Prince tom.prince@ualberta.net wrote:
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!
participants (3)
-
Adi Roiban -
Glyph Lefkowitz -
Tom Prince