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