It is not possible from wip to wip not always work the same things!
Example: In the previous wip the “extend srf” command worked on a truncated cone (the extension worked up over the vertex, in any case, it worked).
In the last wip, nothing to do, no longer works.
In prox wip will be correct, and then it will happen that nothing else will work.
But would it be possible to put some fixed points? Something certain? working?
In the end, I always try to test the usual commands that work in a discontinuous way. Going so far Rhino 6 will not be even more efficient and stable in 2020!
Mah … (small vent, excuse me).
You may have experienced the GPU tessellation bug that was introduced in the last WIP which caused dynamic preview of some geometry to not be drawn. This is fixed in the latest WIP. This was a cosmetic bug in that the core geometry calculations were still the same and being executed; just nothing was being drawn to show you that. It was a mistake; sorry.
Frustrating situation for the user.
The "extend srf "command (to name a random one), a wip yes and a no, runs intermittently. It corrects a bug and creates another, always the same …
So you become crazy!
We multiply everything for each wip, and then for each version of Rhino (n.6, then n.7 …)
A chaos! A confusion!
Understanding every difficulty and the remarkable complexity in developing a code, but a stable point must exist, or not?
Unfortunately, that is the way software development sometimes goes. If you want a rock-solid product, stick with Rhino 5 until Rhino 6 is released, and even then, preferably wait a few service releases until you make the switch. If you need Rhino 6 for some reason or other, you need to make a careful choice if what it gives you compared to Rhino 5 weighs up against the sometimes frustrating bugs that pop up.
TL;DR: Don’t expect the same level of stability of a product that is not even in beta stage yet.
Yes it must. And at the moment that stable point is the latest service release of Rhino5. Rhino6 is currently a work-in-progress, meaning we’re actively changing code all the time, sometimes on low levels. It can be very difficult to see all the possible implications of a low-level code change; it may fix one or more bugs over here while surreptitiously creating a new bug around the corner. We know this makes the software unreliable, but it is a necessary stage in a development process that is not trivially incremental. We need people to test RhinoWip so that these problems are found, but we also acknowledge that the Wip is not an ideal platform for professional work.
Once RhinoWip becomes the Rhino6 Release Candidate, we will no longer be making sweeping changes to core code and it will become a more reliable product. Once we’re happy with how reliable Rhino6 RC is, we’ll stop selling Rhino5 and switch over. At this point you’d be well within your right to get really upset if the software broke on a week-to-week basis, as Rhino6 is now supposed to be the ‘stable point’. But until then, using RhinoWip is risky.
Wouldn’t be possible to script some predefined and automated tests with a visual
comparison of results between versions 5 and 6. So the problem would be anticipated and solved before each new
release?
David Rutten, I understand the whole thing, what you say is correct and I agree.
Only a point is unclear: the discontinuous function of many commands. A wip first works, the wip will no longer work, with the risk that bugs will be dragged from wip to wip and jump out in a more mature and consolidated phase.
That’s all!
It happened with Rhino 5 wip (software I’ve tested for several years). So you risk losing too much useless time, turning and twisting on the same problems…