cairo-Version-Information       package:RGtk2       R Documentation

_V_e_r_s_i_o_n _I_n_f_o_r_m_a_t_i_o_n

_D_e_s_c_r_i_p_t_i_o_n:

     Compile-time and run-time version checks.

_M_e_t_h_o_d_s _a_n_d _F_u_n_c_t_i_o_n_s:

     'cairoVersion()'
      'cairoVersionString()'

_D_e_t_a_i_l_e_d _D_e_s_c_r_i_p_t_i_o_n:

     Cairo has a three-part version number scheme. In this scheme, we
     use even vs. odd numbers to distinguish fixed points in the
     software vs. in-progress development, (such as from git instead of
     a tar file, or as a "snapshot" tar file as opposed to a "release"
     tar file).

     _____ Major. Always 1, until we invent a new scheme.
     /  ___ Minor. Even/Odd = Release/Snapshot (tar files) or
     Branch/Head (git)
     | /  _ Micro. Even/Odd = Tar-file/git
     | | /
     1.0.0
      Here are a few examples of versions that one might see.

     Releases
     --------
     1.0.0 - A major release
     1.0.2 - A subsequent maintenance release
     1.2.0 - Another major release

     Snapshots
     ---------
     1.1.2 - A snapshot (working toward the 1.2.0 release)

     In-progress development (eg. from git)
     --------------------------------------
     1.0.1 - Development on a maintenance branch (toward 1.0.2 release)
     1.1.1 - Development on head (toward 1.1.2 snapshot and 1.2.0
     release)


_C_o_m_p_a_t_i_b_i_l_i_t_y:

     The API/ABI compatibility guarantees for various versions are as
     follows. First, let's assume some cairo-using application code
     that is successfully using the API/ABI "from" one version of
     cairo. Then let's ask the question whether this same code can be
     moved "to" the API/ABI of another version of cairo.

     Moving from a release to any later version (release, snapshot,
     development) is always guaranteed to provide compatibility.

     Moving from a snapshot to any later version is not guaranteed to
     provide compatibility, since snapshots may introduce new API that
     ends up being removed before the next release.

     Moving from an in-development version (odd micro component) to any
     later version is not guaranteed to provide compatibility. In fact,
     there's not even a guarantee that the code will even continue to
     work with the same in-development version number. This is because
     these numbers don't correspond to any fixed state of the software,
     but rather the many states between snapshots and releases.

_E_x_a_m_i_n_i_n_g _t_h_e _v_e_r_s_i_o_n:

     Cairo provides the ability to examine the version at either
     compile-time or run-time and in both a human-readable form as well
     as an encoded form suitable for direct comparison. Cairo also
     provides a function ('cairoVersionEncode()') to perform the
     encoding.


     Compile-time
     --------
     R users should not be concerned with compile-time version
     checking.

     Run-time
     --------
     cairoVersionString()    Human-readable, use compareVersion() for
     comparison
     cairoVersion()          Encoded, not very useful in R
      For example, checking that the cairo version is greater than or
     equal to 1.0.0 could be achieved at compile-time or run-time as
     follows:


     # R users should not be concerned with compile-time checking, but
     at runtime:

     if (compareVersion(cairoVersionString(), "1.0.0") == 1)
       cat("Running with suitable cairo version:",
     cairoVersionString(), "\n")



_A_u_t_h_o_r(_s):

     Derived by RGtkGen from GTK+ documentation

_R_e_f_e_r_e_n_c_e_s:

     <URL:
     http://www.cairographics.org/manual/cairo-Version-Information.html>

