I agree that it makes sense for bug fixes to list all versions (branches) the fix was applied; we’ll also add CHANGES entry under the same version headings, except for unreleased versions.
But for new features, it is different. The CHANGES entry is only added to the first version the feature was introduced (e.g. 7.0.0), even if the feature is committed to master, branch_7x, branch_7_0. In my head it would make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 6. jul. 2017 kl. 08.50 skrev Dawid Weiss <[email protected]>: > >> As David mentioned, there isn’t a >> single true ‘solution’ for this problem so the more information we provide >> the better. > > Think of it in terms of how your repository is structured: > > This issue was *fixed* on git branches [x,y,z] and *affected* tags [a,b,c]. > > This gives a clear an unambiguous pointer and workflow as to what goes > where. "Affected version" can only point to a tag in git (this > requires every proper release to be tagged, of course). "Fix-for" > points at *all* branches (and tags) a given issue has been applied to > (whether it's the same patch or a backport). Certain branches may not > have anything to do with particular versions yet (branch_6x, master, > major_feature_xyz), others are versions-in-preparation (branch_6_5_1; > so-called release branches). > > The additional work (typically of the release manager) is to, when a > given version is being released, add a tag of that particular release > to "fix-for". If the process is followed by everyone this becomes > fairly automatic and results in issues being marked as, for example: > > Fix-for: branch_6x, master, 6.5.1, 7.0 > > All of the above makes sense -- as a developer you immediately see > which git branches this issue was applied to. So do people who are not > developers. > > But like I said before, I'm not advocating for this process -- just > wanted to highlight an example of how it can be done. The above > process does require a fairly strict workflow from everyone involved, > so it may be more suited for a corporate environment... But it is > clear (to me at least), verbose, and fairly straightforward, so it > certainly can be done. > > D. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
