Release rbtools 0.5
Review Request #3974 — Created March 18, 2013 and submitted
Release rbtools 0.5 Provide the release notes for 0.5, and bump the version number.
Built the documentation with 'make html'
Description | From | Last Updated | ||
---|---|---|---|---|
Two blank lines. |
|
|||
"RBTools" |
|
|||
Maybe just say "The new rbt command line tool provides ..." |
|
|||
Thinking these should be, for this release, listed as a child of the "rbt" header. In fact, I'd say we … |
|
|||
Missing period. Same on other similar lines. |
|
|||
Capitalize the sentence. Comma after "optionally" |
|
|||
:option:`--close-type` |
|
|||
"Print" shouldn't be capitalized. I'd actually leave out the "standard out" bit. Too technical. "To the screen" would be fine. |
|
|||
:option:`--diff-revision` |
|
|||
post-review's |
|
|||
directory's |
|
|||
Comma after "Optionally" |
|
|||
"repository" |
|
|||
:envvar:`P4PORT` |
|
|||
That's an internal note. Let's not put it in the release notes. |
|
|||
ClearCase. This doesn't really tell me what the implications of this fix are. It should tell the user why this … |
|
|||
This is an internal thing only we care about (for the most part), and "shebang" is not a very commonly … |
|
|||
Too many blank lines. |
|
|||
"Perforce" |
|
|||
Comma after "file". "Review Board" I'd also change this sentence to be past-tense. "If you made ... Review Board would … |
|
|||
:command:`p4 info` |
|
|||
Past-tense. :command:`p4 info` Actually, this whole description is confusing and doesn't really tell me much of anything. It should be … |
|
|||
ClearCase. |
|
|||
ClearCase. This isn't so much about post-review now, so I'd say "posting review requests." Same with the description below. |
|
|||
"snapshot views" We shouldn't say things like "Changes were made." Rather, we should describe what the bug was. |
|
|||
Internal implementation. Nuke it. Users don't care. |
|
|||
2 blank lines. |
|
|||
:command:`svn` |
|
|||
This is going into imlementation. Just focus on what the problem was and that it's now fixed. |
|
|||
2 blank lines. |
|
|||
Internal changes aren't something we generally put in release notes. If people care, they can look at commits. Our release … |
|
|||
March 19 now :( |
|
|||
There are no open issues |
-
-
-
-
-
Thinking these should be, for this release, listed as a child of the "rbt" header. In fact, I'd say we should structure this like: rbt === This is the initial release of our new command line tool, rbt. It provides blah blah. There are a number of built-in sub-commands. rbt attach ~~~~~~~~~~ etc.
-
-
-
-
"Print" shouldn't be capitalized. I'd actually leave out the "standard out" bit. Too technical. "To the screen" would be fine.
-
-
-
-
-
-
-
-
ClearCase. This doesn't really tell me what the implications of this fix are. It should tell the user why this matters.
-
This is an internal thing only we care about (for the most part), and "shebang" is not a very commonly known term (it might actually be pretty misleading). Let's nuke it.
-
-
-
Comma after "file". "Review Board" I'd also change this sentence to be past-tense. "If you made ... Review Board would choke ..." We also shouldn't include the "suspect it's a regression" part.
-
-
Past-tense. :command:`p4 info` Actually, this whole description is confusing and doesn't really tell me much of anything. It should be rewritten to be clear about how it impacted me as a user.
-
-
ClearCase. This isn't so much about post-review now, so I'd say "posting review requests." Same with the description below.
-
"snapshot views" We shouldn't say things like "Changes were made." Rather, we should describe what the bug was.
-
-
-
-
-
-
Internal changes aren't something we generally put in release notes. If people care, they can look at commits. Our release notes are much more user-facing.