I performed a local install of povray 3.7.0 beta 29 on Linux -- the freshest
beta tarball I saw available at http://www.povray.org/beta/ . After installing
to $HOME/usr/ , I attempted to render a scene and was greeted with the short
error message "povray: this pre-release version of POV-Ray for Unix has
expired".

After searching around, I discovered I needed to set the POVRAY_BETA environment
variable as explained in the previous thread:
http://news.povray.org/povray.beta-test/thread/%3C476af506$1@news.povray.org%3E/
The result of command 'povray --betacode' for me was 2021509749, which is what I
set $POVRAY_BETA to. When I render scenes now, the first line I see printed is
"povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and
23 hour(s)".

I had a few questions about the business with POVRAY_BETA, and am hoping someone
more knowledgeable on this list could shed some light:

1.) What is the point of enforcing this expiration date? Is the intent just to
force users to update their beta versions regularly?
2.) Why is the expiration time so short for a recently downloaded beta? Are
there plans to release a new beta sometime in the next three days?
3.) Is there an easy way to disable the expiration completely? I'd rather not
have to continually muck with the POVRAY_BETA variable. I experimented setting
my system clock
to three days in the future, and sure enough I was again greeted with the
"povray: this pre-release version of POV-Ray for Unix has expired" message, so
I'm anticipating problems with POVRAY_BETA after three days.

Thanks for any answers.

Josh

Post a reply to this message

"Josh Kupershmidt" <schmiddy^at^gmail^dot^com> wrote:
> 1.) What is the point of enforcing this expiration date? Is the intent just to
> force users to update their beta versions regularly?

Yes. The basic idea is to make people stay aware that they're using a beta, and
encourage them to check for a new version occasionally.

So the POV team has built a "self-destruction timer" into the software that will
typically kick in even before the next beta is out, and force people to take
action every week.


> 2.) Why is the expiration time so short for a recently downloaded beta? Are
> there plans to release a new beta sometime in the next three days?

That's two questions at once. (a) The beta may be recently downloaded, but it is
quite old already. (b) I guess not.


> 3.) Is there an easy way to disable the expiration completely? I'd rather not
> have to continually muck with the POVRAY_BETA variable. I experimented setting
> my system clock
> to three days in the future, and sure enough I was again greeted with the
> "povray: this pre-release version of POV-Ray for Unix has expired" message, so
> I'm anticipating problems with POVRAY_BETA after three days.

There are two ways of addressing this:

(a) Get a copy of the POV-Ray beta source code, and "amputate" the beta expiry
code (don't ask me what source file it was in - I've browsed through the source
tree but can't find it at once, so I'll leave that tedious task up to you).

(b) Use a shell script to actually start the beta.

Both approaches work fine (I use the former for my test versions for the
radiosity code, and the latter for the regular binary), and both are perfectly
legal provided you are the only person using the software, and you don't
redistribute it either.

I suggest using (b) because it's the least hassle.

Just make sure you still check for a new beta version occasionally. And keep in
mind that you're not running a stable release - this is work in progress you're
using.

That means, most of all:

- *do* report problems you notice; beta releases are not there for your
entertainment while you are waiting for the final release, but to get a broader
"test base" for the work in progress. (Do not be discouraged if you don't get a
reply from the dev team though.)

- *expect* problems; like most software testing activity, beta tests are not
there to prove that the software is free from bugs (it will never be), but to
find as many of them as possible, so they can be solved.

Post a reply to this message

Thanks for the answers and advice, clipka. I'll probably make a shell script to
update POVRAY_BETA as necessary. I noticed the Gentoo guys including a 3.7.0
beta went the route of informing the user to reset POVRAY_BETA by hand when
povray refuses to run.

http://article.gmane.org/gmane.linux.gentoo.cvs/100211

Thanks again,
Josh

"clipka" <nomail@nomail> wrote:
> "Josh Kupershmidt" <schmiddy^at^gmail^dot^com> wrote:
> > 1.) What is the point of enforcing this expiration date? Is the intent just to
> > force users to update their beta versions regularly?
>
> Yes. The basic idea is to make people stay aware that they're using a beta, and
> encourage them to check for a new version occasionally.
>
> So the POV team has built a "self-destruction timer" into the software that will
> typically kick in even before the next beta is out, and force people to take
> action every week.
>
>
> > 2.) Why is the expiration time so short for a recently downloaded beta? Are
> > there plans to release a new beta sometime in the next three days?
>
> That's two questions at once. (a) The beta may be recently downloaded, but it is
> quite old already. (b) I guess not.
>
>
> > 3.) Is there an easy way to disable the expiration completely? I'd rather not
> > have to continually muck with the POVRAY_BETA variable. I experimented setting
> > my system clock
> > to three days in the future, and sure enough I was again greeted with the
> > "povray: this pre-release version of POV-Ray for Unix has expired" message, so
> > I'm anticipating problems with POVRAY_BETA after three days.
>
> There are two ways of addressing this:
>
> (a) Get a copy of the POV-Ray beta source code, and "amputate" the beta expiry
> code (don't ask me what source file it was in - I've browsed through the source
> tree but can't find it at once, so I'll leave that tedious task up to you).
>
> (b) Use a shell script to actually start the beta.
>
> Both approaches work fine (I use the former for my test versions for the
> radiosity code, and the latter for the regular binary), and both are perfectly
> legal provided you are the only person using the software, and you don't
> redistribute it either.
>
> I suggest using (b) because it's the least hassle.
>
> Just make sure you still check for a new beta version occasionally. And keep in
> mind that you're not running a stable release - this is work in progress you're
> using.
>
> That means, most of all:
>
> - *do* report problems you notice; beta releases are not there for your
> entertainment while you are waiting for the final release, but to get a broader
> "test base" for the work in progress. (Do not be discouraged if you don't get a
> reply from the dev team though.)
>
> - *expect* problems; like most software testing activity, beta tests are not
> there to prove that the software is free from bugs (it will never be), but to
> find as many of them as possible, so they can be solved.

Post a reply to this message

Josh Kupershmidt wrote:
> Thanks for the answers and advice, clipka. I'll probably make a shell script to
> update POVRAY_BETA as necessary. I noticed the Gentoo guys including a 3.7.0
> beta went the route of informing the user to reset POVRAY_BETA by hand when
> povray refuses to run.

    or you can try http://software.inl.fr/trac/wiki/Macfly

Post a reply to this message