<div dir="ltr">Hi,<div><br></div><div>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.<br clear="all"><div><br></div><div>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 </div><div> </div><div>-------</div><div><br></div><div>My proposal for implementing this is:</div><div><br></div><div>Each release will have a new milestone with the same name called 'next-release'. </div><div><br></div><div>Once the changes for a ticket were merged the ticket is assigned to the 'next-release' milestone.</div><div><br></div><div>When release is done, the next-release is renamed to the release name and all previous tickets will be auto-updated.</div><div><br></div><div>A new milestone called 'next-release' is created.</div><div><br></div><div>Invalid or duplicate tickets should not have the 'next-relesese' milestone.</div><div><br></div><div>-----------</div><div><br></div><div>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.</div><div><br></div><div>I don't like tags as when a ticket is landed we don't know if next release will be16.0 or 15.6.</div><div><br></div><div>We can use a 'next-release' tag and when a release is done, check all tickets and update their tag.</div><div><br></div><div>--------</div><div><br></div><div>Please send your suggestions and comments.</div><div><br></div><div>Thanks!</div><div><br></div><div><br></div>-- <br><div class="gmail_signature">Adi Roiban</div>
</div></div>