On Fri, Nov 9, 2018 at 10:52 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

On Fri, Nov 9, 2018 at 2:43 AM Joaquin M López Muñoz via Boost wrote:

...

Maybe some other protocol is needed for handling release notes.

You mean, like, merging them?

Regards

I think a better strategy would be to define release notes in yaml in each repository and then have the website builder scrape those release notes. Merging them all into a single file is not working and clearly more work than should be required. "1_69_0": - note: Added perfect forwarding support. type: normal links: - type: trac id: 13345 - type: github-issue id: 21 - type: github-pr id: 42 - note: Removed public interface. type: breaking - note: Deprecated such-and-such. type: deprecation We could have a Cebrerus schema validator file (in boostorg/website) for the release note language. The website build could fail (optionally) if any of the release notes did not meet the validator. - Jim

On Fri, Nov 9, 2018 at 11:10 AM stefan via Boost wrote:

On 2018-11-09 11:06 a.m., James E. King III via Boost wrote:

...

On Fri, Nov 9, 2018 at 10:52 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Fri, Nov 9, 2018 at 2:43 AM Joaquin M López Muñoz via Boost wrote:

...

Maybe some other protocol is needed for handling release notes. You mean, like, merging them?

Regards

I think a better strategy would be to define release notes in yaml in each repository and then have the website builder scrape those release notes. Merging them all into a single file is not working and clearly more work than should be required.

Amen !

Stefan

Perhaps a better schema... 1_69_0: breaks: - note: Removed public something-or-other. links: - type: trac id: 13356 deprecations: - note: >- The header boost/pending/whatever.hpp has been moved to some other location. This is a long release note. Not too long, but long enough to show the YAML text operator in use. Enjoy. links: - type: github_pr id: 42 notes: - note: made it twice as fast comment: github issues and pulls can use the same URL format (the issue one) links: - type: github id: 21 - type: github id: 79

On 2018-11-09 11:41 a.m., Mateusz Loskot via Boost wrote:

On Fri, 9 Nov 2018 at 17:06, James E. King III via Boost wrote:

...

On Fri, Nov 9, 2018 at 10:52 AM Vinnie Falco via Boost wrote:

...

On Fri, Nov 9, 2018 at 2:43 AM Joaquin M López Muñoz via Boost wrote:

...

Maybe some other protocol is needed for handling release notes. You mean, like, merging them?

I think a better strategy would be to define release notes in yaml (...) You mean, reno?

[...] Let's not get side-tracked into another tools & languages discussion. I think the high-order bit of the proposal is to further modularize the process by letting individual projects manage *their* release notes, then somehow syndicate them. If we could already agree on that as a (mid-term) goal, that would be great. The rest (languages, schemas, tools) can be discussed separately. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 2018-11-09 11:56 a.m., Mateusz Loskot via Boost wrote:
> On Fri, 9 Nov 2018 at 17:47, stefan via Boost  wrote:
>> Let's not get side-tracked into another tools & languages discussion.
>> I think the high-order bit of the proposal is to further modularize the
>> process by letting individual projects manage *their* release notes,
>> then somehow syndicate them.
> Despite I support your views on pushing the modularisation further,
> I am as optimistic about pushing it wild
> - even American Wrestling has rules :)
>
> Eventually, things will have to integrate somehow, there will have to
> be common conventions, formats, tools to make all the wild libs
> running free behave at common table.

The approach I would favour doesn't require different projects to agree 
on tools or formats. It would only require projects to publish release 
notes, and then provide an URL for it, so the toplevel (boost) website 
could have a table containing links.

In fact, that's an idea I already brought up in the past about 
modularizing documentation: if all projects adopt the practice of 
publishing their docs (including release notes) on 
boostorg.github.com/ (e.g. http://boostorg.github.io/gil/ :-), 
all the boost website builder has to do is set up a table with 
project-specific references (to docs, release notes, issue trackers, 
etc.). In that picture no-one cares how you produce those for your 
project (and what issue tracker you use), as long as those references 
are published correctly.

Then people can love & hate yaml et al. as much they want, this would 
never again have to start a boost-wide discussion. Wouldn't that be nice 
? :-)


Stefan

--

       ...ich hab' noch einen Koffer in Berlin...
     

On 11/9/18 7:06 PM, James E. King III via Boost wrote:

On Fri, Nov 9, 2018 at 10:52 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Fri, Nov 9, 2018 at 2:43 AM Joaquin M López Muñoz via Boost wrote:

...

Maybe some other protocol is needed for handling release notes.

You mean, like, merging them?

Regards

I think a better strategy would be to define release notes in yaml in each repository and then have the website builder scrape those release notes.

I hate yaml...