Fixed #20104 -- Changed VersionDirective in order to avoid ambiguity.

As explained in ticket #20104, the use of versionchanged/versionadded
was confusing.

To solve this ambiguity these directives no longer accept a second
argument but now they only receive the version number (1st arg) and then
a content with the proper comment.
This commit is contained in:
Juan Catalano 2013-03-24 22:48:23 -07:00 committed by Claude Paroz
parent 3be8165b62
commit 4e25198ec2
2 changed files with 12 additions and 8 deletions

View File

@ -64,21 +64,25 @@ class VersionDirective(Directive):
option_spec = {} option_spec = {}
def run(self): def run(self):
if len(self.arguments) > 1:
msg = """Only one argument accepted for directive '{directive_name}::'.
Comments should be provided as content,
not as an extra argument.""".format(directive_name=self.name)
raise ValueError(msg)
env = self.state.document.settings.env env = self.state.document.settings.env
ret = [] ret = []
node = addnodes.versionmodified() node = addnodes.versionmodified()
ret.append(node) ret.append(node)
if self.arguments[0] == env.config.django_next_version: if self.arguments[0] == env.config.django_next_version:
node['version'] = "Development version" node['version'] = "Development version"
else: else:
node['version'] = self.arguments[0] node['version'] = self.arguments[0]
node['type'] = self.name node['type'] = self.name
if len(self.arguments) == 2:
inodes, messages = self.state.inline_text(self.arguments[1], self.lineno+1)
node.extend(inodes)
if self.content: if self.content:
self.state.nested_parse(self.content, self.content_offset, node) self.state.nested_parse(self.content, self.content_offset, node)
ret = ret + messages
env.note_versionchange(node['type'], node['version'], node, self.lineno) env.note_versionchange(node['type'], node['version'], node, self.lineno)
return ret return ret

View File

@ -188,8 +188,8 @@ Our policy for new features is:
release, not the development version. release, not the development version.
Our preferred way for marking new features is by prefacing the features' Our preferred way for marking new features is by prefacing the features'
documentation with: "``.. versionadded:: X.Y``", followed by an optional one documentation with: "``.. versionadded:: X.Y``", followed by a a mandatory
line comment and a mandatory blank line. blank line and an optional content (indented).
General improvements, or other changes to the APIs that should be emphasized General improvements, or other changes to the APIs that should be emphasized
should use the "``.. versionchanged:: X.Y``" directive (with the same format should use the "``.. versionchanged:: X.Y``" directive (with the same format