On 06/04/2015 11:26 AM, Sandro Santilli wrote: > On Thu, Jun 04, 2015 at 11:06:31AM +0200, Matthias Kuhn wrote: > >> However, if you leave the "Fixes #XXXX" message in place it will >> generate a new hash when backported (cherry-picked), which will be >> linked in the ticket as well and return release-2_8 when evaluated by >> the tracker. >> >> The downside of this approach is that we do know that it's fixed in >> release-2_8 but not in which point release. So if I fix something today >> it says "fixed in 2.8" but to be precise it should say "fixed in 2.8.3". > True, we don't know about the future (who does?). > What we can know, though, is which release came out from that branch last: > > $ git describe > final-2_8_2-9-gea447e7 > > So, 2.8.2 was the latest, and "we" (a plugin?) may assume 2.8.3 will be > the next. > > I don't like the version in the commit log because if you further > cherry-pick that commit in another branch it brings with it the target > version info which doesn't really belong to the change. In postgis I often > cherry-pick commits from svn-trunk to svn-21 to svn-20 ... I did an example:
http://hub.qgis.org/issues/12867 > Agreed. So back to Paolo's request: > > On Wed, Jun 03, 2015 at 06:29:36PM +0200, Paolo Cavallini wrote: >> My aim was to give "normal" users an easy way of >> discovering whether they can expect a fix in the next LTR release, or if >> they have to head for next release. > I think "normal user" refer to "a fix" by looking at a ticket, > so this whole discussion should be about making retriving the info > from the ticket easier. > > For sure the first step is _ensuring_ that any fix has a ticket. > Then, the ticket should allow containing information about versions > in which the fix was committed. Either using the existing "Target Version" > field (which would need to be turned into an array or represent the "Minimum > Target Version"), or adding a new field. > > --strk; -1 I don't open tickets for bugs which I fixed and found no ticket. I am too lazy. I'd rather have a solution that merges the commit log and the ticket information into a single, good-looking changelog. Matthias _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
