Move releasenotes/ from website repo to main JMRI repo? about jmri HOT 5 CLOSED

Can we also make the release notes a markdown file and have ant convert them into HTML?

I've also found that its sometimes difficult to follow changes in test releases. Can we make the release notes include all changes since the prior production release?

from jmri.

I’m currently finishing a check on all links and markup of the 173(!) release notes from JMRI/website/. Please move them after I checked them in.
I didn’t get the impression they were automatically generated, as I came across a lot of flavors and hand made tags.

I do see the advantage of reusing all the notes, maybe in a template that pulls other standard information like download links, Yahoo group and Java download links plus a CSS styling template from a central place that’s easier to maintain and keep current.

Op 25 okt. 2015, om 16:40 heeft Randall Wood [email protected] het volgende geschreven:
Can we also make the release notes a markdown file and have ant convert them into HTML?

I've also found that its sometimes difficult to follow changes in test releases. Can we make the release notes include all changes since the prior production release?

—
Reply to this email directly or view it on GitHub #114 (comment).

from jmri.

If we use the GitHub releases mechanism, the release notes need to be Markdown, not HTML, if we want to display them with the downloads.

from jmri.

I'm slowly rethinking the release notes.

It looks more likely that we can mark pull requests with "milestones" to get a complete list of changes in a release. C.f. https://github.com/JMRI/JMRI/issues?utf8=✓&q=milestone%3A4.1.4+ I think if that page starts to get attention, people will write more useful titles & descriptions for their pull requests.

We'll still need lots of text for warnings, big items that should be called out, etc. But having a detailed list of changes is going to be nice.

If we do have people putting their own changes into the release note (whether HTML or MD), we're going to start getting collisions from the pull-request process. A change will be in a pull request for a bit, somebody else will make a change to the same release note, and we'll have to manage inevitable overlaps. It's too much editing in the same part of a single file. So I'm not sure that having the release note in JMRI/JMRI helps all that much.

from jmri.

I'm going to close this Issue. I haven't figured out a good way to include release note updates in the JMRI repository tree (so that they can be updated as part of pull requests) without causing way too many conflicts with overlapping-edits on the file(s).

Perhaps the best solution is to have better pull-request comments, so that the list of included PRs can become a core part of the release note.

from jmri.