|GMime 2.4 Reference Manual|
Changes from 2.0 to 2.2
Changes from 2.0 to 2.2 — Incompatible changes made between version 2.0 and version 2.2
See also the PORTING document in the toplevel GMime source directory.
There are no incompatible changes between 2.0 and 2.2.
GMime 2.2 is both API and ABI compatible with GMime 2.0 meaning that any program written for GMime 2.0 will compile fine with GMime 2.2 and any program linked against GMime 2.0's libraries will also work with GMime 2.2's libraries.
Most of the changes made between 2.0 and 2.2 were internal but there are a few API changes you should be aware of (as these interfaces will be deprecated in some future version, probably 3.0).
g_mime_utils_8bit_header_decode() has been split
into 2 functions. We now have
g_mime_utils_header_decode_text() no longer
requires encoded-words to be rfc822 atoms.
still strict in that encoded-words MUST be valid rfc822 atoms.
g_mime_utils_8bit_header_encode() has been
be more clear as to what type of header this is supposed to encode. If
you haven't guessed, this function is for encoding rfc822 'text'
headers (such as Subject).
g_mime_utils_8bit_header_encode_phrase() has been
mostly for consistancy with the previous 2 changes.
g_mime_charset_name() has been renamed to
g_mime_charset_iconv_name() for clarity.
g_mime_charset_locale_name() has been renamed to
g_mime_cipher_context_verify() no longer returns
a GMimeCipherValidity, instead it returns a
GMimeSignatureValidity which is far more
useful. Never fear, you may still use the
GMimeCipherValidity APIs for the time being -
they work fine given a GMimeSignatureValidity
g_mime_multipart_signed_verify() also now returns
a GMimeSignatureValidity structure rather than
a GMimeCipherValidity structure. See changes to
g_mime_cipher_context_verify() for details.