[Discussion] Preparing for the upcoming v0.19 release

[Joel_graff]

Sounds good, and thanks to your work we aren't now in the position, on how to create the release notes in a week or two. It's just about ironing out the details, if any.

Oy. I was supposed to have that done by now. lol. Maybe I can get it tomorrow.

[uwestoehr]

FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

The trails workbench is not in our list: External_workbenches. Could you please add it?

[triplus]

New feature oriented pull request likely should start to be postponed and to be targeted at the next development cycle:

https://forum.freecadweb.org/viewtopic.php?f=10&t=44149

Now i guess we need to start discussing a release date. In April i see that there are some holidays around the weekend involving April 12. Therefore i guess dates around April 5 or April 19 are better candidates.

Opinions?

[uwestoehr]

Now i guess we need to start discussing a release date.
Opinions?

Personally, I began to update the Wiki. This needs some time and will for sure result in new PRs to change here and there a menu name, tooltip etc.

Then we are all facing lockdowns due to COVID making it hard to make predictions when we will find time for FC. Family and health first!

So what about asking here very Monday for opinions of the WB maintainers what time they will need to e.g. polish the UI/documentation/translation? Then it is much easier to make a decision.

[triplus]

Personally, I began to update the Wiki. This needs some time and will for sure result in new PRs to change here and there a menu name, tooltip etc.

This one is a bit tricky, as it involves translations too. That is, at some point we will need to cut this cycle, in April. But indeed, now is the time for that cycle to be ongoing. Such pull requests for sure won't be considered being a feature oriented ones.

Then we are all facing lockdowns due to COVID making it hard to make predictions when we will find time f FC. Family and health first!

By all means, but for now there are no mayor health issues reported, by people involved in a release procedure, hence for now COVID-19 isn't getting in the way.

So what about asking here

Yes, that is the point. April 2020 was i guess on the schedule for the past half year. Now we are near April, hence best to determine if we are aiming to do a release at a beginning or at the end of April. As there is a week of holidays in the middle in a lot of countries, likely therefore the middle of the April is not all that appropriate.

[triplus]

IMHO it's time to do a release. Fiddling with FreeCAD 0.19 any further won't change much. And what is up with FreeCAD 0.18.5. Still something we plan to do? In addition there are roughly 50 PRs pending consistently in the past month. Therefore we i guess won't lower that number anytime soon. Having additional "freeze" window would likely only backfire. As PR count would only grow during such time frame and after we would need to take care of 300 PRs.

Bottom line, what FreeCAD needs the most is a release date, all other dates are less important. And on release date, FreeCAD needs to get released. For the past half year it was said FreeCAD 0.19 will get released in April 2020. Therefore lets release FreeCAD 0.19 in April 2020?

P.S. After i guess we need to discuss on how to proceed. As volume of PRs and volume of massive code changes is becoming a bit unmanageable. Stressing the upstream in such way over the longer periods of time can start to have negative effects. What can we do to mitigate that?

[vocx]

...As PR count would only grow during such time frame and after we would need to take care of 300 PRs.
...
P.S. After i guess we need to discuss on how to proceed. As volume of PRs and volume of massive code changes is becoming a bit unmanageable. Stressing the upstream in such way over the longer periods of time can start to have negative effects. What can we do to mitigate that?

The number of pending PR doesn't matter. Each author should know the reason he or she opened that pull request. We have to assume each pull request is made with the best intentions to improve the software, so whether it is merged before a certain date, in one release or another, is not important, unless it is made to correct significant bugs in the code.

Each author should thoroughly comment their pull requests in order to really explain why that pull request is being made. I try to do that, even if it's a bit boring and verbose. The other thing is learning to use the Git system well. In many cases authors add too many commits where they change one thing, and then change it again in the next commit. This makes it a bit difficult to review the code. So authors should try to make their commits as compact as possible, and squash certain commits together, so that review is easy to do, not only by the administrators but also by other users interested in the changes.

A personal recommendation. I've been merging various pull requests lately, and I've had to edit and rebase many times, so I've noticed that this becomes difficult when a single branch has too many commits. So I propose a soft rule that a single pull request shouldn't introduce more than 10 commits at the same time. If we need to add more commits, then these should come in a second pull request that follows from the first. Say, pull request #5000 with 10 commits, and Part 2 in #5001 with 8 commits. Then we can review the first one and then the second one more easily. Also, if we need to change the history of some commits, and then rebase, this can be done more easily.

[triplus]

Nah it doesn't work like that. Bottom line, if we have a feature freeze for a month, somebody will need to manage 300 PRs after. That is in my opinion just too stressful for the upstream on the long run. And now we are deep in the April and people still do heavy restructuring of some modules and add features such as App::Link support for some features ... Just like we are at the beginning of the development cycle.

P.S. Anyway, we have toyed with this for (too) long enough and now the situation has changed. We can decide to release today or tomorrow, the binaries for FreeCAD 0.18.5 and FreeCAD 0.19 won't be available on all platforms in foreseeable future.

https://forum.freecadweb.org/viewtopic.php?f=42&t=45412

Therefore as far as i am concerned we have already missed that window of opportunity, to make a release in predictable way. Likely there is some painful packaging transition ahead again, that will take months, at best.

[adrianinsaval]

So what happened with the release? I haven't seen much discussion about it recently, is it being discussed elsewhere? Are there ongoing preparations for it?

[triplus]

Last year some key people have set the release date to happen around April 2020. As that didn't happen i am guessing it could still take a couple of months. Likely there are still some C++ items left on the todo list, due to the merge of big efforts, such as the App::Link. Heavy Draft restructuring effort is likely contributing to a bit of a setback too. And last but not least, there is summer ahead. I somehow doubt, that majority of people involved, wants to dedicate the whole summer in achieving this goal, that is to achieve the release ASAP.

Long story short, if other key people won't signal otherwise, to me therefore October or November sounds like a more realistic goal. Main ongoing preparations left therefore being sorting out the C++ side of things, to start next development cycle in a good shape in this regard and i guess for the Draft restructuring effort to start settling down.