> On Dec 4, 2015, at 4:51 AM, Adi Roiban <a...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
