On Thu, Oct 01, 2026 at 06:59:55PM -0700, Revar Desmera via Discuss wrote:

I don't feel like logging into github today. So I comment here.

I think it is a good idea to think about the possiblity for making
this the default in the future early on in the process.

I think that these octa spheres are much better in almost all aspects
so that changing the default makes OpenScad better.

And I think that a global $sphere_style = "octa"; is a good way to
test if an existing project behaves correctly with the new spheres.
(during the testing phase where it isn't yet the default).

And when it is eventually made the default , $sphere_style = "orig";
is a good way to keep compatiblity.

Adding an option that people can set that sets the default if there is
no $sphere_style = ... in the source is also a good idea. This option
should also be allowed to be "unset" (no value), so that the openscad
default applies. If you don't allow that, people who simply open and
save the settings in the "octa exists but isn't the default" would
not eventually be migrated to the new default.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ  Delfgauw, The Netherlands.
** KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a** is going up.  -- Chris Hadfield about flying up the space shuttle.
**  'a' for accelleration.

On 10/2/2026 11:11 AM, Rogier Wolff via Discuss wrote:

Well, OK, but it means that your comments are somewhat ephemeral.

I'd like that too.  It's not clear whether compatibility is too large a
concern to make it practical.  (I am sure that it depends on who you ask.)

I would like to make it so that newcomers get the best behavior
practical, even at some compatibility expense.

Give or take the exact name, that's my best candidate for a transition plan.

I think there are three issues with that scheme (and my responses):

• Namespace.  As with almost every new name that we create, there is
  the possibility that it will collide with somebody's existing usage.
  o As with almost every name that we create, I think that way lies
  insanity.  Unless we can fix our naming to prevent collisions,
  we're stuck with that risk and must not let it paralyze us.
• Leakage into libraries.  You know that your program is "safe" with
  the setting, but how do you know that the libraries that you use are
  "safe"?
  o Libraries need to pay attention to evolution too, and you need
  to keep your libraries updated.  A library that needs the old
  behavior, like a main program that needs it, can set the $
  variable to control behavior inside it, and that will work (and
  be ignored) on older releases.
• Compatibility breaks should never be allowed.
  o The future is always larger than the past (or, if it isn't,
  there's not much point to development).  Making things better
  for future work is worth minor compatibility breaks (with
  appropriate transition plans).

Any other issues?