Release notes for v0.19

[triplus]

We have been talking about adding possible QtWebEngine support for years now and it has just happened:

https://github.com/FreeCAD/FreeCAD/pull/1937

Likely it makes sense to mention that. Under i guess the general notes about the current state of porting to Python 3 and Qt 5 (or under Web Workbench). A note that porting to Python 3 and Qt 5 effort is considered done and mature. That will likely make sense too. At the end of the development cycle. As a month or two back, most developer already stated, they have moved to using Py3/Qt5 toolchain.

[sliptonic]

mlampert's PR 2056 was merged today.

This adds the ability to have multiple copies of a Path job base object.

[triplus]

Yes, this is the ideal scenario. When a module developer(s) highlights a notable feature added. Some text, images or videos can get accumulated under an appropriate release notes sections. Like Path module section. Otherwise it would be hard to understand and keep track of everything, for a single person.

[Joel_graff]

Yes, this is the ideal scenario. When a module developer(s) highlights a notable feature added. Some text, images or videos can get accumulated under an appropriate release notes sections. Like Path module section. Otherwise it would be hard to understand and keep track of everything, for a single person.

I'll go through and add this here in the next day or two - getting pulled in several directions lately.

If I can just get 'tickled' here that there's an update / bug fix / feature add to put in the release notes, I have no problem digging further and finding better images, developing a description, etc, as well as noting the changes to the owner if they have a forum topic currently active.

Just wish I could make sense of coming through Mantis / github commits to update from there.

[Kunda1]

I think we need something automated especially as the project grows, or @joelgraff you're subject to getting overwhelmed and we need you focused because of all the awesome work you do on Civil stuff. Automated in a way where the info you need is mostly there and easily apprehended. How do other projects do this?...and in a way where it frees up the core developers to focus more on core stuff.

[sliptonic]

It's always a judgements call about what to include. The developer is probably the one best able to make the call.
The github pull request template has a set of questions like 'is the commit message well written?' perhaps it could include a question "does this pr include a feature to be included in the release notes?"

[Kunda1]

It's always a judgements call about what to include. The developer is probably the one best able to make the call.
The github pull request template has a set of questions like 'is the commit message well written?' perhaps it could include a question "does this pr include a feature to be included in the release notes?"

I agree, if we add it hopefully it doesn't discourage developers from contributing because writing documentation can be annoying.

[Joel_graff]

I agree, if we add it hopefully it doesn't discourage developers from contributing because writing documentation can be annoying.

It's always a judgements call about what to include. The developer is probably the one best able to make the call.

I tend to agree the devs should be primarily responsible for the release note content - it just makes the most sense, really.

It might be more useful to stay within this thread and use it as a portal for managing the release notes. To that end, I can update the release notes when I get notice here. Before a release, I can ping the owners / devs of the various workbenches to review the release notes and update them or at least provide me with updated information so I can update the wiki.

[sliptonic]

I agree, if we add it hopefully it doesn't discourage developers from contributing because writing documentation can be annoying.

It's always a judgements call about what to include. The developer is probably the one best able to make the call.

I tend to agree the devs should be primarily responsible for the release note content - it just makes the most sense, really.

Yes. And No.
The dev is DEFINITELY the best one to make the decision. Whether they actually write the release note content kinda depends on what we want release notes to look like. If the pull request and commit messages are, in fact, well written, then there should be enough information present to write the release note as long as the notes are just text. But if they're going to be richer and include images, gifs, links, etc, then I wouldn't expect the dev to do that. I'd rather have them working on the next feature.

[Joel_graff]

The dev is DEFINITELY the best one to make the decision. Whether they actually write the release note content kinda depends on what we want release notes to look like.

Right - I expect to write the release notes myself unless the dev would rather handle that. Having consistent formatting and concise summaries are critical because it's a public-facing document. But if I can get the majority of the notes to 'come to me' here, I'll definitely take that over hunting them down.