Since POV-Ray (for Windows, at least, I don't know about other systems)
is already able to access the internet to give some feedback or check
for updates, why not :
- set an expiration date in the binary
- once the expiration date is over, if there is no new beta,
   POV-Ray can get some kind of "certificate" which allows it
   to continue working as long as the Team wishes.

(of course, this has problems like "not every machine running
  POV-Ray has internet access", etc.. but it might be a nice
  solution for most people)

It could also take the form of some "licence file".

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Since POV-Ray (for Windows, at least, I don't know about other systems)
> is already able to access the internet to give some feedback or check
> for updates, why not :
> - set an expiration date in the binary
> - once the expiration date is over, if there is no new beta,
>    POV-Ray can get some kind of "certificate" which allows it
>    to continue working as long as the Team wishes.
>
> (of course, this has problems like "not every machine running
>   POV-Ray has internet access", etc.. but it might be a nice
>   solution for most people)
>
> It could also take the form of some "licence file".
>
> Fabien.

Or built-in unlock codes that are only released by the team when necessary.
(beta expires with no new one available)

-tgq

Post a reply to this message

Trevor G Quayle wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Since POV-Ray (for Windows, at least, I don't know about other systems)
>> is already able to access the internet to give some feedback or check
>> for updates, why not :
>> - set an expiration date in the binary
>> - once the expiration date is over, if there is no new beta,
>>    POV-Ray can get some kind of "certificate" which allows it
>>    to continue working as long as the Team wishes.
>>
>> (of course, this has problems like "not every machine running
>>   POV-Ray has internet access", etc.. but it might be a nice
>>   solution for most people)
>>
>> It could also take the form of some "licence file".
>>
>> Fabien.
> 
> Or built-in unlock codes that are only released by the team when necessary.
> (beta expires with no new one available)
> 
My suggestion still is to compile a few beta's with different expiry 
dates and release an extended beta when necessary. That costs a 
recompile but there is no change of the current code required.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Trevor G Quayle wrote:
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> Since POV-Ray (for Windows, at least, I don't know about other systems)
> >> is already able to access the internet to give some feedback or check
> >> for updates, why not :
> >> - set an expiration date in the binary
> >> - once the expiration date is over, if there is no new beta,
> >>    POV-Ray can get some kind of "certificate" which allows it
> >>    to continue working as long as the Team wishes.
> >>
> >> (of course, this has problems like "not every machine running
> >>   POV-Ray has internet access", etc.. but it might be a nice
> >>   solution for most people)
> >>
> >> It could also take the form of some "licence file".
> >>
> >> Fabien.
> >
> > Or built-in unlock codes that are only released by the team when necessary.
> > (beta expires with no new one available)
> >
> My suggestion still is to compile a few beta's with different expiry
> dates and release an extended beta when necessary. That costs a
> recompile but there is no change of the current code required.

However this would require downloading and installing the binary. Not that
that would generally be a problem, you need to do this if it were a new
beta anyways, however people are always averse to extra downloads.
I don't think an automatic checker would work either as that requires being
able to connect through a network and this isn't always possible for some
users due to set-up or permissions.
This is why I think built in unlock codes would work best.  Users are
already visiting the download page to get the new beta, so if the
applicable valid code is posted it's a simple matter of feeding it to POV
when it asks, no extra download required (still would need a capable net
connection, but this would only require browsing permissions).  Using this
could also eliminate the need for adding a click-through warning screen for
extended betas, which also seems to be undesirable.

-tgq

Post a reply to this message

As a Pov-Ray user of many years ago I was delighted to find the project 
still alive and well. I went to download the current beta and found it 
not there. As I have a dual core machine I really wanted to get an idea 
of how the new code performs. I fully understand the need to keep the 
beta process under control, but ...

How about adding code to the beta for the bug reporting. When the beta 
expires you would no longer be able to submit bugs with that version. 
Also after expiration the program would fire up a nag screen at startup 
with whatever message the developers desire. You could also include a 
"final expiration" to prevent the use of the code after some extended 
time. As an alternative you could require all bug reports to include a 
key from the beta program. After expiration the key would become invalid 
and bug report process would reject those reports.

Rick

Fa3ien wrote:
> Since POV-Ray (for Windows, at least, I don't know about other systems)
> is already able to access the internet to give some feedback or check
> for updates, why not :
> - set an expiration date in the binary
> - once the expiration date is over, if there is no new beta,
>   POV-Ray can get some kind of "certificate" which allows it
>   to continue working as long as the Team wishes.
> 
> (of course, this has problems like "not every machine running
>  POV-Ray has internet access", etc.. but it might be a nice
>  solution for most people)
> 
> It could also take the form of some "licence file".
> 
> Fabien.

Post a reply to this message

I wanted to download 3.7 because I have a quad CPU, but surprise - no beta
;-(

I propose to overlap beta and release date a bit so nobody has to be
disappointed.

You could even disable the expiary dates if you build some automatic
patching into the code for the differences between beta and release. So
transmission of the differences would be small and you could even update
bug fixes of released POV-rays.

Hope I can test 3.7 soon!

Best regards
Joerg

Post a reply to this message

"JoergS" <nomail@nomail> wrote:
> I wanted to download 3.7 because I have a quad CPU, but surprise - no beta
> ;-(
>
> I propose to overlap beta and release date a bit so nobody has to be
> disappointed.
>
> You could even disable the expiary dates if you build some automatic
> patching into the code for the differences between beta and release. So
> transmission of the differences would be small and you could even update
> bug fixes of released POV-rays.
>
> Hope I can test 3.7 soon!
>
> Best regards
> Joerg

Perhaps this can even go hand-in-hand with built in bug reporting.  That way
a few items are addressed:
1) the offending code is readily available and can be forwarded
automatically
2) the resulting error can be forwarded as well
3) bug reporting can continue even after the final release, with patching
allowing for fututre bug fixes not caught during beta testing.
3) in beta testing phases (or even after final release)  bug reports from
discontinued betas (and final releases that haven't been patched) can be
disabled without disabling the program.

Just some thoughts, all this is likely something that wouldn't be feasible
for the current beta phases, but a possibility for future versions (i.e.
POV4)

-tgq

Post a reply to this message