-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Noting changes towards 2.50 #725
Conversation
* NEW: jenkinsci/jenkins#2765 * NEW: jenkinsci/jenkins#2778 * NEW: jenkinsci/jenkins#2780 * NEW: jenkinsci/jenkins#2683 * NEW: jenkinsci/jenkins#2773 * UPD: jenkinsci/jenkins#2772
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice and detailed changelog!
content/_data/changelogs/weekly.yml
Outdated
pull: 2765 | ||
- type: rfe | ||
message: > | ||
API: Allow providing a custom task name in Run/Schedule UI via the <code>AlternativeUiTextProvider</code> extension. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API is ambiguous, there's also the (user) remote API
content/_data/changelogs/weekly.yml
Outdated
@@ -87,7 +87,81 @@ | |||
date: 2017-03-11 | |||
changes: | |||
- type: rfe | |||
message: Expose the noun for an item when behaving as a task via <tt>AlternativeUiTextProvider</tt>. | |||
message: > | |||
Allow searching by build param values in the Build history widget. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lowercase build
, write parameter
instead of param
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or "Build History widget"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either works. Not sure how we're usually using it.
It will collide with #739 |
@@ -87,7 +87,82 @@ | |||
date: 2017-03-11 | |||
changes: | |||
- type: rfe | |||
message: Expose the noun for an item when behaving as a task via <tt>AlternativeUiTextProvider</tt>. | |||
message: > | |||
Allow searching by build parameter values in the <code>Build History</code> widget. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should reserve code formatting for things that are technical in nature, e.g. Method names, class names, file names, etc.
I don't think this needs any special formatting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tt
then?
For technical things we may also want to introduce the Javadoc macro in yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oleg-nenashev Both are inappropriate IMO. em, strong if you need to emphasize something. But neither this nor the versions below qualify.
pull: 2780 | ||
- type: bug | ||
message: > | ||
Update Remoting from <code>3.5</code> to <code>3.7</code> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
@daniel-beck