[oXygen-sdk] Request to enhance the oXygen version detection in a plugin addon.

[Michael Anthony Smith]

Hi Radu,

Thanks for the 'ro.sync.util.Resource.getBuildNumber()' method call, this does just what I want. 

It appears that the build numbers have the form 'YYYYmmddhh', where:
   'YYYY' is a 4-digit year
  'mm' is a 2-digit month of the year (between 01-12)
  'dd' is a 2-digit day of the month (between 01-31)
  'hh' is a 2-digit hour of the day (between 00-23)

I have coded my OxygenVersion object with this semantics.

Best regards,
Anthony.
--
Michael Anthony Smith
Senior Software Engineer

DeltaXML Ltd "Experts in information change"

T:	+44 1684 532 140 
E:	anthony.smith at deltaxml.com 
W:	http://www.deltaxml.com
Malvern Hills Science Park, Malvern, Worcs, WR14 3SZ, UK
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On 7 Apr 2014, at 13:42, "Oxygen XML Editor Support (Radu Coravu) " <support at oxygenxml.com> wrote:

> Hi Michael,
> 
> We'll consider adding this new API in the 
> ro.sync.exml.workspace.api.WorkspaceUtilities interface for a new version.
> 
> But in the meantime you can call the static method:
> 
>> ro.sync.util.Resource.getBuildNumber()
> 
> The method is not obfuscated in our code and it should return the 
> application's build number.
> 
> Regards,
> Radu
> 
> Radu Coravu
> <oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
> 
> On 4/7/2014 12:46 PM, Michael Anthony Smith wrote:
>> A workspace plugin can obtain the version string associated with the
>> oXygen Editor/Author/Developer that it is being run in by using the
>> getVersion method of the StandalonePluginWorkspace object that is
>> provided to it. It would be useful if we could also obtain the build
>> number (and possibly the release date)* from within a plugin, so that
>> its behaviour can be adjusted depending on the build-number (or release
>> date).
>> 
>> *The build numbers alone are probably fine, as they are likely to be
>> monotonically increasing, so we can simply test to see if the current
>> build number is greater than a specified build number to determine if it
>> is later release.
>> 
>> Example: If a feature of a plugin is known to work with some, but not
>> all patch releases of a given oXygen release, then it would be possible
>> to tailor the behaviour of the plugin to:
>> (1) switch off the feature for oXygen patch releases that it is known
>> not to work in;
>> (2) let the user know why a given feature is not available; and potentially
>> (3) let the user know that in order to get access to the feature they
>> need to get the latest version of say the '15.2' version of oXygen.
>> 
>> Best regards,
>> Anthony.
>> *--*
>> *Michael Anthony Smith*
>> Senior Software Engineer
>> 
>> *DeltaXML Ltd*/"Experts in information change"/
>> *
>> *
>> *T*:+44 1684 532 140
>> *E*:anthony.smith at deltaxml.com <mailto:anthony.smith at deltaxml.com>
>> *W*:http://www.deltaxml.com
>> Malvern Hills Science Park, Malvern, Worcs, WR14 3SZ, UK
>> Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
>> 
>> 
>> _______________________________________________
>> oXygen-sdk mailing list
>> oXygen-sdk at oxygenxml.com
>> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>> 
> _______________________________________________
> oXygen-sdk mailing list
> oXygen-sdk at oxygenxml.com
> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20140407/63b4eeb6/attachment.html>