Am 06.04.2016 um 16:10 schrieb whenuwishupon:
> I solved the problem for master source code. I forgot to select Windows Targets
> -> console as start-up Project. 92 warnings, but povconsole64.exe is there.
> Now I will test it.
> what's the difference between stable and master source code?
The stable branch holds the latest official release, currently 3.7.0.
Any behaviour -- whether intentional or otherwise -- of a "stable"
release becomes "canonical" in the sense that you can reasonably expect
future versions to behave in the same manner, provided you make proper
use of the "#version" statement. (Behaviour resulting from bugs that a
user cannot possibly mistake for being intentional is routinely exempt
from this protection, and features explicitly reported as "experimental"
also have some risk of being intentionally changed as well.)
Also, "stable" versions have undergone a phase of pure bugfixing, so
presumably they contain comparatively few bugs.
The master branch, on the other hand, is where development happens,
currently in preparation for what will become 3.7.1.
On the upside, this means that the version will contain the latest and
greatest new features.
On the downside, any behaviour of a development version that differs
from the previous stable release may be subject to change without notice.
Also, development versions are more prone to bugs.
At present however, the value of the "stable" branch happens to be
greatly diminished by the following factors:
- C++11: The new standard has become widely adopted /after/ the latest
stable version; as it turns out, POV-Ray contained various
incompatibilities with the new standard, so contemporary build
environments like Visual Studio 2015 or modern versions of GCC gag on
the latest stable version. Even in the master branch the C++11-related
problems have only recently been ironed out completely.
- Boost and Automake: Both boost 1.50 and a comparatively recent
Automake incarnation introduced some breaking changes that interfered
with our Unix build process, and which we found time to work around only
after the latest stable release (mainly because the primary developers
are notorious Windows jockeys).
- Sub-optimal software lifecycle management: Ideally, when bugs or
issues are discovered that were already present in the latest stable
version, they should be fixed in the stable branch and then ported to
the development branch. However, in the past, both feature and bugfixing
development has been made on the master branch, and to this day nobody
has made the endeavour to isolate and port those fixes to the stable branch.
Post a reply to this message