Answers.Body: <p>As Coleman suggests, one can do more direct inspections to see if particular entities/actions/fields are supported. This is generally more robust/correct in the long-run, but it can be problematic in some edge-cases. There is a way to get the version number.</p>
  
  <p>In CiviCRM v4.4+, use the System.get API, e.g.</p>
  
  <pre><code>drush cvapi system.get
  Array
  (
      [is_error] =&gt; 0
      [version] =&gt; 3
      [count] =&gt; 1
      [id] =&gt; 0
      [values] =&gt; Array
          (
              [0] =&gt; Array
                  (
                      [version] =&gt; 4.4.17
                      [uf] =&gt; Drupal
                  )
  
          )
  )
  </code></pre>
  
  <p>Of course, checking an API is mildly expensive. <em>If</em> you need to guard many statements with version checks, then it could add up. To mitigate this:</p>
  
  <ul>
  <li>If using the API remotely to inspect system state, cache the data for a few minutes.</li>
  <li>If writing server-side PHP code, don't use an API. Instead, call <code>CRM_Utils_System::version()</code> and <a href="http://php.net/version_compare" rel="nofollow">version_compare()</a>.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-13T21:17:54.493Z
Answers.LastActivityDate: 2015-07-13T21:17:54.493Z
Answers.UserDisplayName: Tim Otten
Answers.Body: <p>At a most levels, yes you can query the api for certain features. For example:</p>
  
  <pre><code>civicrm_api3('Entity', 'get');
  </code></pre>
  
  <p>will tell you all available entities.</p>
  
  <pre><code>civicrm_api3('Contact', 'getactions');
  </code></pre>
  
  <p>will tell you all available actions for e.g. the Contact entity.</p>
  
  <pre><code>civicrm_api3('Contact', 'getfields', array('action' =&gt; 'create'));
  </code></pre>
  
  <p>will tell you all available fields for e.g. the Contact::create action.</p>
  
  <pre><code>civicrm_api3('Contact', 'getoptions', array('field' =&gt; 'prefix_id'));
  </code></pre>
  
  <p>will tell you available options for a certain field, e.g. the Contact individual_prefix.</p>
  
  <hr>
  
  <p>However, your question is about specific option to be passed into the "options" array, which unfortunately is completely undocumented as far as api metadata goes. I'd love for this shortcoming to be addressed, particularly because the api explorer is suffering because of it.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-12T17:38:09.367Z
Answers.LastActivityDate: 2015-07-12T17:38:09.367Z
Answers.UserDisplayName: Coleman
Body: <p>when writing extensions, i often try to keep the code compatible with several versions of civi instead of having to maintain different branches.</p>
  
  <p>however, i sometimes would like to use a new feature <strong>if it's available</strong>, for instance, civi 4.6 introduced <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/API+changes#APIchanges-4.6.0:Added%27force_rollback%27option" rel="nofollow">an option to force rollback</a> that i would like to use, but if i'm using this option and run the code with civi 4.5, it will silently ignore it and won't rollback.</p>
  
  <p>is there a way from the api to test the version that is running, or -my preference- if a specific feature is implemented?</p>
  
Tags: <api>
Title: how to test the version-or if a feature is implemented?
ThreadText: # how to test the version-or if a feature is implemented?
  
  (Asked by: username_0 on 2015-07-12)
  
  when writing extensions, i often try to keep the code compatible with several versions of civi instead of having to maintain different branches.
  
  however, i sometimes would like to use a new feature **if it's available**, for instance, civi 4.6 introduced [an option to force rollback](http://wiki.civicrm.org/confluence/display/CRMDOC/API+changes#APIchanges-4.6.0:Added%27force_rollback%27option) that i would like to use, but if i'm using this option and run the code with civi 4.5, it will silently ignore it and won't rollback.
  
  is there a way from the api to test the version that is running, or -my preference- if a specific feature is implemented?
  
  **Tags:** api
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-07-13. Score: 2 | Accepted answer
  
  As username_2 suggests, one can do more direct inspections to see if particular entities/actions/fields are supported. This is generally more robust/correct in the long-run, but it can be problematic in some edge-cases. There is a way to get the version number.
  In CiviCRM v4.4+, use the System.get API, e.g.
  drush cvapi system.get
  Array
  (
      [is_error] => 0
      [version] => 3
      [count] => 1
      [id] => 0
      [values] => Array
          (
              [0] => Array
                  (
                      [version] => 4.4.17
                      [uf] => Drupal
                  )
  
          )
  )
  
  Of course, checking an API is mildly expensive. If you need to guard many statements with version checks, then it could add up. To mitigate this:
  
  If using the API remotely to inspect system state, cache the data for a few minutes.
  If writing server-side PHP code, don't use an API. Instead, call CRM_Utils_System::version() and version_compare().
  
  
  ---
  
  ### Answer by username_2 on 2015-07-12. Score: 1
  
  At a most levels, yes you can query the api for certain features. For example:
  civicrm_api3('Entity', 'get');
  
  will tell you all available entities.
  civicrm_api3('Contact', 'getactions');
  
  will tell you all available actions for e.g. the Contact entity.
  civicrm_api3('Contact', 'getfields', array('action' => 'create'));
  
  will tell you all available fields for e.g. the Contact::create action.
  civicrm_api3('Contact', 'getoptions', array('field' => 'prefix_id'));
  
  will tell you available options for a certain field, e.g. the Contact individual_prefix.
  
  However, your question is about specific option to be passed into the "options" array, which unfortunately is completely undocumented as far as api metadata goes. I'd love for this shortcoming to be addressed, particularly because the api explorer is suffering because of it.
  
  
  ---
  
  