> This would be a break in tradition. We don't (or haven't in the past) > done release notes for point releases, as they are normally only > bugfixes and/or security updates. > > I can see three possiblities here: > > 1. Mark the feature as 'versionadded:1.2" in trunk; in the 1.1.X > branch, mark it 'versionadded:1.1', but with an explanatory note > clarifying that strictly, it's 1.1.2.
A bit hackish, but passable. > 2. Mess around with the Sphinx processor and make it display point > release numbers but link to the minor release. A big -1 if documentation can only be built with a custom version of Sphinx, making it harder for others to build docs. A -0 if it's something in stock Sphinx that can be twiddled via configuration/setup. > 3. Actually create a 1.1.2 release notes document, whose sole purpose > is to document this extraordinary feature. > > I don't have any preference on the color of this particular bikeshed. > If pressed, I'd probably say option 3. As Luke said, "the circumstances which created the need for this are rare", so #3 sounds like the right way to handle it -- an anomalous trigger gets an anomalous "break in tradition"... It also sounds like what first came to Luke's mind as a solution, making it three minds agreeing with no dissenting suggestions. -tim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
