El 21/02/13 23:22, Jim Henderson escribió:
> Nor I.  I've done what I can to help out when I've had time or the
> necessary contacts to help facilitate things, which seems "fair" (in the
> sense that I'm trying to give /something/ back, but it always feels
> inadequate).

   That's because POV-Ray, as an endless source of fun, is priceless...

--
Jaime

Post a reply to this message

On Mon, 25 Feb 2013 18:03:42 +0100, Jaime Vives Piqueres wrote:

> El 21/02/13 23:22, Jim Henderson escribió:
>> Nor I.  I've done what I can to help out when I've had time or the
>> necessary contacts to help facilitate things, which seems "fair" (in
>> the sense that I'm trying to give /something/ back, but it always feels
>> inadequate).
> 
>    That's because POV-Ray, as an endless source of fun, is priceless...

:)

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Thu, 21 Feb 2013 01:24:24 -0500, Jim Henderson wrote:
>
> > In all seriousness, ISTR there being a place on the POV-Ray site where
> > that specific answer was given - it used to be a FAQ, and the answer was
> > "don't ask - it'll be released when it's ready and not one minute
> > sooner".
>
> Ah, yes.  Here:
>
> http://tinyurl.com/bjugxlq
>
> Note the second paragraph from the end:
>
> "Please note that there is no firm schedule for the final release of
> POV-Ray 3.6. We have a reputation of releasing very stable software and
> intend that to remain so. The final version will be released when we are
> happy with it, and not before. We cannot give a date for this!"
>
> You're welcome.
>
> Jim

I think it's also that we get hung up on the idea of software versions these
days, always wanting the latest and greatest.  At this point POV is really
superceding this concept, and version numbering is somewhat irrelavant other
than putting things in historical order.  Even the "release candidate"
designations are no longer really relaese candidates, with all the major changes
that have been occuing in them.  Each release is just a growth of the previous
and at this point it doesn't really look like there will ever be a final 3.7, as
there will always be something new soneone wants to add.  The RC series just
represent a continuing growth of the current software.  Arguably, any number of
the RC versions could've been upgraded to "POV 3.8", etc..  The only thing that
would represent a traditional step to "POV 4.0" would probably be more a change
in the interface, however, in the sense of how POV operates, this would be less
minor than it would imply as POV is more about the underlying power and function
than how the interface looks (it is not a modelling software).

That said, perhaps there is some argument to stop calling the releases release
candidates (unless I am mistaken and there is some end-date at which it will be
'complete').  Perhaps move to calling it just "POV-Ray" with less focus on the
version number.  Of course version or build numbering would still need to be
kept superficially to keep track of where we are in POV's timeline.

I do know there is traditional reasoning and convention in the software industry
on how version numbering is done, however, I don't think POV really fits in the
traditional software model, and following such conventions can lead to confusion
from the unitiated such as this.

Taka a look for example at CHDK (hacked add-on firmware for Canon cameras for
those not familiar).  Basically it is not traditionally versioned, but
constantly (daily) has the latest 'build' updated on the server.  Each build may
be the same as the last, or it may include updates to the software whether minor
or major.

Something along this lines would be nice as it would help foster the continual
growth of POV.  Rather than feature requests sometimes being "that'll have to
wait until 4.0", if someone has the time and means to implement it into the
code, it can be verified and added to the build at any time.

Maybe just ramblings, or maybe some ideas to think about.  Eaither way version
numbering for POV has long been of no interest for me.  I'm more interested in
functionality: what can it do now, and what can it be made to do soon.

-tgq

Post a reply to this message

On Mon, 25 Feb 2013 13:46:58 -0500, Trevor G Quayle wrote:

> software.  Arguably, any number of the RC versions could've been
> upgraded to "POV 3.8", etc..  The only thing that would represent a
> traditional step to "POV 4.0" would probably be more a change in the
> interface, however, in the sense of how POV operates, this would be less
> minor than it would imply as POV is more about the underlying power and
> function than how the interface looks (it is not a modelling software).

Actually, what's been stated is that 4.0 is going to be released under a 
new license (GPLv3 IIRC, but I could be remembering incorrectly). :)

> I do know there is traditional reasoning and convention in the software
> industry on how version numbering is done, however, I don't think POV
> really fits in the traditional software model, and following such
> conventions can lead to confusion from the unitiated such as this.

Version numbering historically is used as a way of marking what features 
are enabled and how "up to date" you are relative to the current release.

Then marketing departments got hold of it, and version numbers are often 
decided on what marketing value they have.

> Something along this lines would be nice as it would help foster the
> continual growth of POV.  Rather than feature requests sometimes being
> "that'll have to wait until 4.0", if someone has the time and means to
> implement it into the code, it can be verified and added to the build at
> any time.

Build dates are useful as long as you have only one build per day. :)  Of 
course, you can get more granular than that.  The way Rockbox is versioned 
is a traditional versioning scheme, but whenever talking about self-built 
packages, it's easier to refer to the subversion revision (r12345) than a 
version number. :)

> Maybe just ramblings, or maybe some ideas to think about.  Eaither way
> version numbering for POV has long been of no interest for me.  I'm more
> interested in functionality: what can it do now, and what can it be made
> to do soon.

Same here, and I often wonder what it is that gets people hung up on a 
version number.  It's the features that are important.

Jim

Post a reply to this message

Photoshop has every year a new release, the onely way to keep the people from
marketing/developping happy.In Holland we 've got a saying "Never change a
winning horse".

Post a reply to this message

I suppose with version 4 there will be peace over the whole earth, even in the
Middel-East.

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Mon, 25 Feb 2013 13:46:58 -0500, Trevor G Quayle wrote:
>
> > software.  Arguably, any number of the RC versions could've been
> > upgraded to "POV 3.8", etc..  The only thing that would represent a
> > traditional step to "POV 4.0" would probably be more a change in the
> > interface, however, in the sense of how POV operates, this would be less
> > minor than it would imply as POV is more about the underlying power and
> > function than how the interface looks (it is not a modelling software).
>
> Actually, what's been stated is that 4.0 is going to be released under a
> new license (GPLv3 IIRC, but I could be remembering incorrectly). :)
>

Granted that is something that would probably necesitate a version upgrade


> > I do know there is traditional reasoning and convention in the software
> > industry on how version numbering is done, however, I don't think POV
> > really fits in the traditional software model, and following such
> > conventions can lead to confusion from the unitiated such as this.
>
> Version numbering historically is used as a way of marking what features
> are enabled and how "up to date" you are relative to the current release.
>
> Then marketing departments got hold of it, and version numbers are often
> decided on what marketing value they have.
>

But also, the way I understand it (not a versioning expert) is that versioning
has to do with how 'big' of a change it is (does it warrant a full upgrade: 3.0
to 4.0, or a smaller upgrade: 3.7 -> 3.8 or 3.7 -> 3.71).  This is tough to
pigeonhole with current POV development as new items have been added throughout
the RC process without a corresponding change in versioning.


> > Something along this lines would be nice as it would help foster the
> > continual growth of POV.  Rather than feature requests sometimes being
> > "that'll have to wait until 4.0", if someone has the time and means to
> > implement it into the code, it can be verified and added to the build at
> > any time.
>
> Build dates are useful as long as you have only one build per day. :)  Of
> course, you can get more granular than that.  The way Rockbox is versioned
> is a traditional versioning scheme, but whenever talking about self-built
> packages, it's easier to refer to the subversion revision (r12345) than a
> version number. :)
>

I guess my whole point of this is that I have seen the "release candidate" tag
kick around for quite awhile, which would imply some minor fixing of bugs, when
in reality it has become much more than that.  Significant changes and additions
have been included in the releases candidates, and the current discussion do
give any sign that this will change anytime soon.

Was thinking that, with regard to feature addition/upgrade, we can be seen to
have our "3.7" version (not a release candidate), but that the 'build' or
minor/major revisioning is a constant process.

My preference (if it mattered) would be to continue POV development in this
route, where constant (or sporadic as development dictates) change can be
implemented and released.  So that if certain ideas or features are good, work,
and can be implemented in the current framework, then they can be released as a
new build rather than pushed to a new version that could be a long way away.
This is one reason that megaPOV was introduced previously, to push out working
features that didn't want to wait for a new version release to be implemented.
Letting be implemented in a 'build' type process would allow development of POV
to continually evolve, which I think is absolutely suitable for the type of
program that it is.

If it some point a fundamental change such as licensing as you noted, or an
interface upgrade, then at that time a wholesale 'version' update can take
place.

Again, these are just random discussion points on how to break out of the 'when
is the new version coming out' mindset that doesn't work very well for POV.

-tgq

Post a reply to this message

On Mon, 25 Feb 2013 15:41:29 -0500, Trevor G Quayle wrote:
>> Actually, what's been stated is that 4.0 is going to be released under
>> a new license (GPLv3 IIRC, but I could be remembering incorrectly). :)
>>
>>
> Granted that is something that would probably necesitate a version
> upgrade

Well, there's nothing that *requires* a version number change, as version 
numbers are largely arbitrary.

> But also, the way I understand it (not a versioning expert) is that
> versioning has to do with how 'big' of a change it is (does it warrant a
> full upgrade: 3.0 to 4.0, or a smaller upgrade: 3.7 -> 3.8 or 3.7 ->
> 3.71).  This is tough to pigeonhole with current POV development as new
> items have been added throughout the RC process without a corresponding
> change in versioning.

How "big" a change is is very much in the eye of the beholder.  It's 
difficult to quantify, especially when you use an iterative development 
model that uses incremental changes rather than mass implementation of 
new features.

> I guess my whole point of this is that I have seen the "release
> candidate" tag kick around for quite awhile, which would imply some
> minor fixing of bugs, when in reality it has become much more than that.
>  Significant changes and additions have been included in the releases
> candidates, and the current discussion do give any sign that this will
> change anytime soon.

Perhaps, though I think there is at some point a feature lockdown.  Chris 
would be a better person to answer that.

> Again, these are just random discussion points on how to break out of
> the 'when is the new version coming out' mindset that doesn't work very
> well for POV.

:)

Jim

Post a reply to this message

Am 25.02.2013 20:09, schrieb Jim Henderson:
> On Mon, 25 Feb 2013 13:46:58 -0500, Trevor G Quayle wrote:
>
>> software.  Arguably, any number of the RC versions could've been
>> upgraded to "POV 3.8", etc..  The only thing that would represent a
>> traditional step to "POV 4.0" would probably be more a change in the
>> interface, however, in the sense of how POV operates, this would be less
>> minor than it would imply as POV is more about the underlying power and
>> function than how the interface looks (it is not a modelling software).
>
> Actually, what's been stated is that 4.0 is going to be released under a
> new license (GPLv3 IIRC, but I could be remembering incorrectly). :)

That's actually planned for 3.7 proper. It'll be AGPL though (the 
difference being that it also covers online services).

POV-Ray 4.0 is likely to see distributed rendering (which yet again 
requires quite some work under the hood, even though multiprocessor 
support already took a huge step in that direction), and a major 
overhaul of the parser (essentially a complete re-write, presumably with 
changes in the syntax).

The RC are called Release Candidates because we want the 3.7 release 
proper to be as stable as possible, and the original plan was actually 
to feature-freeze 3.7 during the RC phase, but we found that some 
features called for additional changes that we rather wanted to do in a 
3.6 -> 3.7 transition rather than a 3.7.0 -> 3.7.1 transition (most 
notably gamma and alpha handling in RC1 as well as subsurface scattering 
syntax and a new installer in RC4). So with more extensive testing being 
inevitable, we dared throw in some additional minor features along with 
them.

Since RC4 new features have been added only very sparingly.

Post a reply to this message

On Tue, 26 Feb 2013 00:16:33 +0100, clipka wrote:

>> Actually, what's been stated is that 4.0 is going to be released under
>> a new license (GPLv3 IIRC, but I could be remembering incorrectly). :)
> 
> That's actually planned for 3.7 proper. It'll be AGPL though (the
> difference being that it also covers online services).

That's good to know, I hadn't heard that.  I remember Chris' announcement 
from a couple years back that it was a 4.0 target.

> POV-Ray 4.0 is likely to see distributed rendering (which yet again
> requires quite some work under the hood, even though multiprocessor
> support already took a huge step in that direction), and a major
> overhaul of the parser (essentially a complete re-write, presumably with
> changes in the syntax).

That's good to know as well.  I've been playing with Blender's new Cycles 
renderer off and on for the past few months, and I like the results, but 
I wish it had better configuration for distributing the render (I'm 
trying a test animation render of 500 frames at 720x480/29.97 fps on a 
quad-core system, and it's going to take more than 4 days to complete.  
That's what I get for playing with glass and reflective spheres with the 
new rigid body physics engine).

> The RC are called Release Candidates because we want the 3.7 release
> proper to be as stable as possible, and the original plan was actually
> to feature-freeze 3.7 during the RC phase, but we found that some
> features called for additional changes that we rather wanted to do in a
> 3.6 -> 3.7 transition rather than a 3.7.0 -> 3.7.1 transition (most
> notably gamma and alpha handling in RC1 as well as subsurface scattering
> syntax and a new installer in RC4). So with more extensive testing being
> inevitable, we dared throw in some additional minor features along with
> them.
> 
> Since RC4 new features have been added only very sparingly.

Great info, thanks!

Jim

Post a reply to this message