Hi folks,

The first Release Candidate of v3.7.1 is now available on GitHub:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-rc.1

**IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
release candidate does NOT make any attempt to co-exist with v3.7.0. If
you intend to keep v3.7.0 around, make sure to back up the binaries, or
install v3.7.1 in a different location. You may also want to back up the
include files first. Also, there is no way to prevent the installations
from sharing most settings.


Happy testing!

Post a reply to this message

On 2017-06-23 04:17 PM (-4), clipka wrote:
> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
> release candidate does NOT make any attempt to co-exist with v3.7.0. If
> you intend to keep v3.7.0 around, make sure to back up the binaries, or
> install v3.7.1 in a different location.

I am an active Object Collection contributor, and I test my modules 
across different POV-Ray versions.  Some differences between v3.7.0 and 
v3.7.1 are significant enough that I wish to keep v3.7.0 around.

Regarding the Unix version, I did *not* take your earlier suggestion to 
run the configure script with the --prefix= parameter.  (See "Peaceful 
coexistence between 3.7.0 and 3.7.1" in p.t.tutorials.)  I understand 
this to mean that my beta installs have already been storing data where 
v3.7.0 looks for them.  (I've already noticed the changes in the user 
manual.)  Does this mean that the hack I used to keep both versions 
coexisting should continue to work?

> You may also want to back up the
> include files first.

Done.  So far, the only incompatibility I've noticed is with ior.inc.

> Also, there is no way to prevent the installations
> from sharing most settings.

Theoretically, I have no worries there, but I have yet to address your 
response to my troubles with INI files.

Post a reply to this message

Am 25.06.2017 um 06:31 schrieb Cousin Ricky:
> On 2017-06-23 04:17 PM (-4), clipka wrote:
>> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
>> release candidate does NOT make any attempt to co-exist with v3.7.0. If
>> you intend to keep v3.7.0 around, make sure to back up the binaries, or
>> install v3.7.1 in a different location.
> 
> I am an active Object Collection contributor, and I test my modules
> across different POV-Ray versions.  Some differences between v3.7.0 and
> v3.7.1 are significant enough that I wish to keep v3.7.0 around.

I think the cleanest way to accomplish this is to just back up the 3.7.0
binaries, install 3.7.1, and copy the 3.7.0 binaries back in under a
different name.

You may also need to apply your 3.7.0 `ior.inc` workaround.

> Regarding the Unix version, I did *not* take your earlier suggestion to
> run the configure script with the --prefix= parameter.  (See "Peaceful
> coexistence between 3.7.0 and 3.7.1" in p.t.tutorials.)  I understand
> this to mean that my beta installs have already been storing data where
> v3.7.0 looks for them.  (I've already noticed the changes in the user
> manual.)  Does this mean that the hack I used to keep both versions
> coexisting should continue to work?

To the best of my knowledge, the Unix beta did not install in a separate
directory (as opposed to the Windows beta), so whatever you did on Unix
to keep 3.7.0 and 3.7.1-beta separate should also work for the 3.7.1-rc
and later the 3.7.1 final.

Post a reply to this message

Am 25.06.2017 um 06:31 schrieb Cousin Ricky:

> I am an active Object Collection contributor, and I test my modules
> across different POV-Ray versions.  Some differences between v3.7.0 and
> v3.7.1 are significant enough that I wish to keep v3.7.0 around.

BTW, what differences are we talking about there?

Post a reply to this message

On 2017-06-25 05:24 AM (-4), clipka wrote:
> Am 25.06.2017 um 06:31 schrieb Cousin Ricky:
>
>> I am an active Object Collection contributor, and I test my modules
>> across different POV-Ray versions.  Some differences between v3.7.0 and
>> v3.7.1 are significant enough that I wish to keep v3.7.0 around.
>
> BTW, what differences are we talking about there?

I have a module in the works that tests for inverse square light 
attenuation.

There is also the elimination of the torus spindle artifact, although I 
already had a workaround for that and haven't decided whether it's worth 
the version sniffing just to take advantage of this feature.

But in general, many of the bug fixes and numerous enhancements to v3.7 
have the /potential/ for requiring testing or version sniffing.  This is 
quite different from the upgrades to v3.6.  I do not even remember what 
the difference was between v3.6.0 and v3.6.1, and of course v3.6.2 was a 
Windows-specific change that had no bearing on renders.

Post a reply to this message

On 06/25/2017 12:31 AM, Cousin Ricky wrote:
> On 2017-06-23 04:17 PM (-4), clipka wrote:
>> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
>> release candidate does NOT make any attempt to co-exist with v3.7.0. If
>> you intend to keep v3.7.0 around, make sure to back up the binaries, or
>> install v3.7.1 in a different location.
> 
> I am an active Object Collection contributor, and I test my modules 
> across different POV-Ray versions.  Some differences between v3.7.0 and 
> v3.7.1 are significant enough that I wish to keep v3.7.0 around.
> 
> Regarding the Unix version, I did *not* take your earlier suggestion to 
> run the configure script with the --prefix= parameter.  (See "Peaceful 
> coexistence between 3.7.0 and 3.7.1" in p.t.tutorials.)  I understand 
> this to mean that my beta installs have already been storing data where 
> v3.7.0 looks for them.  (I've already noticed the changes in the user 
> manual.)  Does this mean that the hack I used to keep both versions 
> coexisting should continue to work?
> 
> 

I am currently using the following method to maintain multiple versions 
of POV-Ray on Ubuntu linux for similar testing and support reasons.

I create a tmpUser directory in my own space. Within this directory I 
currently have sub-directories called MyP370, MyP371, MyP372, MyJG, 
MyUber and MyPovr. If you were supporting multiple users on your system 
or creating installable system-images you might create these directories 
in /usr/local/share.

In your local git repository(ies) where the branch(es) are available do 
the usual builds always specifying a prefix:

git checkout release/v3.7.1
cd unix
./prebuild
cd ..
./configure COMPILED_BY="wfp" --prefix=$HOME/tmpUser/MyP371
make -j4
make check
make install

For each branch you want to maintain change the --prefix argument to 
point to the corresponding install space.  In my case the branches are 
currently "3.7-stable", "release/v3.7.1", "master"(3.7.2) and other 
experimental branches including my own "povr" branch for my work version 
of povray.

It's helpful to do a 'make clean' or 'make distclean' after each 'make 
install'.  With the code refactoring over time the clean and distclean 
"targets" have changed due the source code directories getting moved 
around and renamed.  You can skip the cleanup step but you might find 
yourself with, for example, extra "*.o" object files laying around. 
Note you'll get extra directories relative to any particular branch in 
any case.  These extra directories will be empty if you have done the 
distclean step while in the branch where they were valid.

With the differing distributions built and installed, I create small 
wrapper scripts in my $HOME/bin directory to run each. For example, I 
have a p370 bash script which looks like:

------------------ Start -----------------
#!/bin/bash
#--------------------------------------------------
# Wrapper to run local POV-Ray 3.7.0 stable install
#--------------------------------------------------

#-- Use install version's povray.ini over, for example,
#   $HOME/.povray/3.7/povray.ini which might have been
#   customized or be incompatible. If have Library paths
#   important and normally in the home directory, will
#   need to use -L or add additional Library_Path= in temp .ini file.
#
export POVINI=$HOME/tmpUser/MyP370/etc/povray/3.7/povray.ini
echo "" >$HOME/.povray/3.7/povray.ini

#   Note:
#   A similar conflict is possible with
#   $HOME/.povray/<version>/povray.conf. Use $PATH install only.
echo "" >$HOME/.povray/3.7/povray.conf

#--- Run what the user passes for options.
$HOME/tmpUser/MyP370/bin/povray $@

exit $?
------------------ End -----------------

Now instead of the usual:

povray +w800 +h600 the.pov

command use instead one of:

p370  +w800 +h600 the.pov
p371  +w800 +h600 the.pov
p372  +w800 +h600 the.pov
pPovr +w800 +h600 the.pov
pJG   +w800 +h600 the.pov
pUber +w800 +h600 the.pov

One of the awkward parts today is every "make install"(1) puts its own 
versions of povray.ini and povray.conf into the users $HOME in a .povray 
sub-directory common for all 3.7 versions.  My view is this isn't 
something "make install" should be doing - rather povray should on start 
look to create these files if need be on a users first invocation. 
Further, better to maintain separate versions for 3.7.0 vs 3.7.1 for 
example.  Anyway, not the way in works today and part of what the 
wrapper scripts do is avoid the stuff in $HOME.

The six distributions currently require just under 300MB of disk space.

(1) - uberpov is set up so as to maintain its own .uberpov directory, 
but I use the same form of wrapper script as all other versions to keep 
things simple.

Bill P.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> The first Release Candidate of v3.7.1 is now available on GitHub:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-rc.1
>
> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
> release candidate does NOT make any attempt to co-exist with v3.7.0. If
> you intend to keep v3.7.0 around, make sure to back up the binaries, or
> install v3.7.1 in a different location. You may also want to back up the
> include files first. Also, there is no way to prevent the installations
> from sharing most settings.
>
>
> Happy testing!

there doesn't seem to be any povwin*.exe under 'downloads'...

Post a reply to this message

Am 27.06.2017 um 17:46 schrieb green:
> clipka <ano### [at] anonymousorg> wrote:
>> Hi folks,
>>
>> The first Release Candidate of v3.7.1 is now available on GitHub:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-rc.1
>>
>> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
>> release candidate does NOT make any attempt to co-exist with v3.7.0. If
>> you intend to keep v3.7.0 around, make sure to back up the binaries, or
>> install v3.7.1 in a different location. You may also want to back up the
>> include files first. Also, there is no way to prevent the installations
>> from sharing most settings.
>>
>>
>> Happy testing!
> 
> there doesn't seem to be any povwin*.exe under 'downloads'...

Sorry for the inconvenience; the release candidate has been retracted
for now, while dev team is examining the possiblity of redesignating the
upcoming version as v3.8.0 rather than v3.7.1.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 27.06.2017 um 17:46 schrieb green:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Hi folks,
> >>
> >> The first Release Candidate of v3.7.1 is now available on GitHub:
> >>
> >> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-rc.1
> >>
> >> **IMPORTANT NOTE:** In contrast to the betas, the Windows version of the
> >> release candidate does NOT make any attempt to co-exist with v3.7.0. If
> >> you intend to keep v3.7.0 around, make sure to back up the binaries, or
> >> install v3.7.1 in a different location. You may also want to back up the
> >> include files first. Also, there is no way to prevent the installations
> >> from sharing most settings.
> >>
> >>
> >> Happy testing!
> >
> > there doesn't seem to be any povwin*.exe under 'downloads'...
>
> Sorry for the inconvenience; the release candidate has been retracted
> for now, while dev team is examining the possiblity of redesignating the
> upcoming version as v3.8.0 rather than v3.7.1.

ok, good.  thanks for the info.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Sorry for the inconvenience; the release candidate has been retracted
> for now, while dev team is examining the possiblity of redesignating the
> upcoming version as v3.8.0 rather than v3.7.1.

But I haven't even started testing beta 9 yet!!  ;-P

"The World is moving too fast..."  Shakespeare (or Mark Twain??)

Post a reply to this message