[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! -- Adi Roiban
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! -- Adi Roiban
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! -- Adi Roiban
participants (3)
-
Adi Roiban -
Glyph Lefkowitz -
Tom Prince