9 posts • Page 1 of 1
In Sketchup, the normal way to check whether the current installed version if newer or older than a given version is to use Sketchup.version_number, which returns a FixNum. Sketchup.version is unfortunately returning a string which is not good for comparison.
A small problem is that the Sketchup.version_number method does not seem to match Sketchup.version. For instance, with the latest release, SU 8.0M2:
- Sketchup.version = "8.0.11752"
- Sketchup.version_number = 8000999
Does anybody remember what was the current version_number for SU8 M1?Thanks
PS: M1 introduced some functional evolutions, and scripts may have to adapt depending on their presence in the version run by the user.
1) Sketchup.version_number is bugged, obviously. I asked them to make it work as it needs to, because it NEVER worked correctly, when the build number was higher than 1000. They are reluctant, because they are afraid of breaking old plugins (I suppose.)
2) I am maintaining a spreadsheet with as many build numbers, as I can determine.
Exactly the question, bound to be raised repeatedly, that led to me creating the Sketchup::Version submodule.
It now needs updating since the release of 8.0M2. (And needs to be released as part of a library package, not on it's own bundled with plugins.)
For now use:
BUILD = Sketchup.version.split('.').last.to_i
where the build numbers are :
Note: Each language has it's own build number, on each platform, in each MR release set. (.. I have not yet determined what all the build numbers are for the various language builds, in the MR2 set.)
NO.. each major AND minor version combination, starts it's build numbers back at 0. (Ie, each major.minor has it's own MRs !!)
So ... The build number ranges for 7.0 are different for 7.1 ...
AND .. logical comparison of the versions strings does not work (because they are not 0 padded.)
can't you do the html 'preferred method' and check for features. eg. defined? $dc_extension
This is what I do usually.
However, since 8.0M1, the view.draw method support coloring of polygons, and there is no new methods to detect apart from testing whether the current SU Version is > M1.
As apparently there is nothing built-in in the Ruby API, I'll have of course to make my way thorugh the major, minor versions and build numbers.
@Dan: thanks for the info. 11752 builds is not bad for a single version 8.0 (~33 years at 1 build per day!)
Firstly.. that's a poor example... because it is an extension (plugin,) not part of the compiled API core.
You could test if a certain method is defined, in a certain module or class, but that runs the risk of being a false positive, IF someone backported that particular method. (Say a 3rd party API "fix" extension, supplies a pure Ruby method that allows older releases to work as later releases.)
I do have plans to provide such "fixed" methods when they are easy to implement. Something like fixing the view.draw methods for older releases, is likely NOT something to happen, in a 3rd party "fix.". It's way too low level, and requires an intimate knowledge of both OpenGL programming and the Sketchup engine. Only the GSUDT could make these fixes.
WHAT !! ... where do you get 33 years from ??
The 8.0 development cycle from start to 8.0.M2 release is no more than 701 DAYS !
... and there are at least 24 more language builds above 11752, so make it 11776 total ...
That's at least 16 (almost 17 builds per day.) Subtract 100 Sundays.
And it's more like 11776 / 601 = at least 19 builds per day, if they worked 6 days a week.
9 posts • Page 1 of 1