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