yep. Advancing the version now means that in case of further db schema
changes 6.0 will be released with internal version number 6.0.x
Somewhere on github I suggested to use 4th digit to track db changes in
development process.
Thus
5.0.8 - release version;
5.0.8.1-5.0.8.xxx - some daily snapshots with DB schema changes;
5.0.9 - the next release version after 5.0.8;
In this case internal version will match version string. E.g. the recent
5.x release (5.0.11) has internal version 5.0.20 and version string
5.0.11 and I remember some curious users asking why is it so. :)
Victor
On 09/16/2013 03:54 PM, Frank Karlitschek wrote:
On 16.09.2013, at 07:33, Bernhard Posselt <[email protected]> wrote:
On 09/16/2013 02:18 AM, Thomas Tanghus wrote:
OC_Filesystem: - file_get_contents/file_put_contents -> OCP\Files
Can be done by using the View class
So I suggest to publish OC::getVersionString() next to
OCP\Util::getVersion().
Can someone explain why we even need to use 5.80? Why not set the
version to 6.0?
6.0 is the version of the ownCloud 6.0 release. We are still pre alpha so the
internal version is 5.8 at the moment. :-)
Frank
I miss basic things like OC_Appconfig::getValue() in the public
interface...
Check OCP\Config::getAppValue()
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
