hiro/releases
1
0
Fork 0
mirror of https://github.com/vale981/releases synced 2025-03-05 17:51:42 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of github.com:bitprophet/releases

Browse source 
Conflicts:
	README.rst
This commit is contained in:
Jeff Forcier 2013-09-24 19:11:03 -07:00
commit 42507f21bd
2 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
README.rst
View file

@ -43,9 +43,9 @@ Mimic the format seen `in Fabric's changelog
* Create a Sphinx document named ``changelog.rst`` with a top-level header * Create a Sphinx document named ``changelog.rst`` with a top-level header
followed by a bulleted list. followed by a bulleted list.
* Bullet list items must use the ``:support:``, ``:feature`` or ``:bug`` roles to * Bullet list items must use the ``:support:``, ``:feature:`` or ``:bug:``
mark issues, or ``:release:`` to mark a release. These special roles must be roles to mark issues, or ``:release:`` to mark a release. These special roles
the first element in each list item. must be the first element in each list item.
* Issue roles are of the form ``:type:`number[ keyword]```. Keywords are * Issue roles are of the form ``:type:`number[ keyword]```. Keywords are
optional and may be one of: optional and may be one of:
@ -109,8 +109,8 @@ TODO
entry is not (IMHO) acceptable. entry is not (IMHO) acceptable.
* Possibly add more keywords to allow control over additional edge cases. * Possibly add more keywords to allow control over additional edge cases.
* Add shortcut format option for the release/issue URI settings - Github users * Add shortcut format option for the release/issue URI settings - GitHub users
can just give their Github acct/repo and we will fill in the rest. can just give their GitHub acct/repo and we will fill in the rest.
* Maybe say pre-1.0 releases consider all bugs 'major' (so one can e.g. put out * Maybe say pre-1.0 releases consider all bugs 'major' (so one can e.g. put out
an 0.4.0 which is all bugfixes). Iffy because what if you *wanted* regular an 0.4.0 which is all bugfixes). Iffy because what if you *wanted* regular
feature-vs-bugfix releases pre-1.0? (which is common.) feature-vs-bugfix releases pre-1.0? (which is common.)

2
releases/__init__.py
View file

@ -175,7 +175,7 @@ def construct_releases(entries, app):
# Handle rare-but-valid non-issue-attached line items, which are # Handle rare-but-valid non-issue-attached line items, which are
# always bugs. (They are their own description.) # always bugs. (They are their own description.)
if not isinstance(focus, issue): if not isinstance(focus, issue):
focus = issue(type_='bug', nodelist=[focus], backported=False, major=False, description=[focus]) focus = issue(type_='bug', nodelist=[focus], backported=False, major=False, description=[])
else: else:
focus.attributes['description'] = rest focus.attributes['description'] = rest
if focus.type == 'bug': if focus.type == 'bug':