POV-Ray : Newsgroups : povray.binaries.images : A quick povr branch micro normal image. : Re: A quick povr branch micro normal image. Server Time
28 Mar 2024 06:03:02 EDT (-0400)
  Re: A quick povr branch micro normal image.  
From: Bald Eagle
Date: 27 Jan 2022 13:40:00
Message: <web.61f2e609c1365d061f9dae3025979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> > Instead of using f_odd() to return additional patch/branch information,
> > I think it should instead return always a value f_odd() cannot. For
> > example, 99.0(a).

> a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> changed stuff ("amplify") as well as version/patch level, everything in one
> place.  :-)
>
>
> regards, jr.

Aside, or perhaps in addition to, what can be done under the hood,

what if the versioning mechanism not only has internal functions, but checks for
the existence of "versions.inc" in the path?  Preferably this would be a
"wrapper" inc file that then looks for the most recent "versions_DateCode.inc"
to use...

That would allow all manner of code to be run based upon the values returned by
the internal function(s), either in addition to, or instead of the "default"
behaviour.

Also, the output for any given version could be easily updated by people in the
absence of any official developer presence / availability / activity.

Also, I would suggest a way to implement Semantic Versioning, so that all the
little changes that get made along the way can be documented.
Maybe a 9-digit number XXXYYYZZZ.

Just thinking about long-term expandability and making the capabilities
available NOW.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.