-/*!
-
- @page backwardcompatibility_overview Backward compatibility
-
- Many of the GUIs and platforms supported by wxWidgets are continuously
- evolving, and some of the new platforms wxWidgets now supports were quite
- unimaginable even a few years ago. In this environment wxWidgets must also
- evolve in order to support these new features and platforms.
- However the goal of wxWidgets is not only to provide a consistent
- programming interface across many platforms, but also to provide an
- interface that is reasonably stable over time, to help protect its users
- from some of the uncertainty of the future.
- @ref versionnumbering_overview
- @ref sourcecompatibility_overview
- @ref libbincompatibility_overview
- @ref appbincompatibility_overview
-
-
- @section versionnumbering The version numbering scheme
-
- wxWidgets version numbers can have up to four components, with trailing
- zeros sometimes omitted:
-
- @code
- major.minor.release.sub-release
- @endcode
-
- A stable release of wxWidgets will have an even number for @c minor, e.g. @c 2.6.0.
- Stable, in this context, means that the API is not changing. In truth, some
- changes are permitted, but only those that are backward compatible. For
- example, you can expect later @c 2.6.x.x releases, such as @c 2.6.1
- and @c 2.6.2 to be backward compatible with their predecessor.
- When it becomes necessary to make changes which are not wholly backward
- compatible, the stable branch is forked, creating a new development
- branch of wxWidgets. This development branch will have an odd number
- for @c minor, for example @c 2.7.x.x. Releases from this branch are
- known as development snapshots.
- The stable branch and the development branch will then be developed in
- parallel for some time. When it is no longer useful to continue developing
- the stable branch, the development branch is renamed and becomes a new
- stable branch, for example @c 2.8.0. And the process begins again.
- This is how the tension between keeping the interface stable, and allowing
- the library to evolve is managed.
- You can expect the versions with the same major and even minor
- version number to be compatible, but between minor versions there will be
- incompatibilities. Compatibility is not broken gratuitously however, so
- many applications will require no changes or only small changes to work
- with the new version.
-
- @section sourcecompatibility Source level compatibility
-
- Later releases from a stable branch are backward compatible with earlier
- releases from the same branch at the source level.
- This means that, for example, if you develop your application using
- wxWidgets @c 2.6.0 then it should also compile fine with all later @c 2.6.x versions. The converse is also @true providing you avoid any new
- features not present in the earlier version. For example if you develop
- using @c 2.6.1 your program will compile fine with wxWidgets @c 2.6.0
- providing you don't use any @c 2.6.1 specific features.
- For some platforms binary compatibility is also supported, see 'Library
- binary compatibility' below.
- Between minor versions, for example between @c 2.2.x, @c 2.4.x and @c 2.6.x, there will be some incompatibilities. Wherever possible the old way
- of doing something is kept alongside the new for a time wrapped inside:
-
- @code
- #if WXWIN_COMPATIBILITY_2_4
- /* deprecated feature */
-...
+/**
+
+@page overview_backwardcompat Backwards Compatibility
+
+Many of the GUIs and platforms supported by wxWidgets are continuously
+evolving, and some of the new platforms wxWidgets now supports were quite
+unimaginable even a few years ago. In this environment wxWidgets must also
+evolve in order to support these new features and platforms.
+
+However the goal of wxWidgets is not only to provide a consistent programming
+interface across many platforms, but also to provide an interface that is
+reasonably stable over time, to help protect its users from some of the
+uncertainty of the future.
+
+@li @ref overview_backwardcompat_versionnumbering
+@li @ref overview_backwardcompat_sourcecompat
+@li @ref overview_backwardcompat_libbincompat
+@li @ref overview_backwardcompat_appbincompat
+
+
+<hr>
+
+
+@section overview_backwardcompat_versionnumbering The Version Numbering Scheme
+
+wxWidgets version numbers can have up to four components, with trailing zeros
+sometimes omitted:
+
+@verbatim
+major.minor.release.sub-release
+@endverbatim
+
+A stable release of wxWidgets will have an even number for @e minor, e.g.
+2.6.0. Stable, in this context, means that the API is not changing. In truth,
+some changes are permitted, but only those that are backward compatible. For
+example, you can expect later 2.6.x releases, such as 2.6.1 and 2.6.2 to be
+backward compatible with their predecessor.
+
+When it becomes necessary to make changes which are not wholly backward
+compatible, the stable branch is forked, creating a new development branch of
+wxWidgets. This development branch will have an odd number for @e minor, for
+example 2.7.x. Releases from this branch are known as development snapshots.
+
+The stable branch and the development branch will then be developed in parallel
+for some time. When it is no longer useful to continue developing the stable
+branch, the development branch is renamed and becomes a new stable branch, for
+example: 2.8.0. And the process begins again. This is how the tension between
+keeping the interface stable, and allowing the library to evolve is managed.
+
+You can expect the versions with the same major and even minor version number
+to be compatible, but between minor versions there will be incompatibilities.
+Compatibility is not broken gratuitously however, so many applications will
+require no changes or only small changes to work with the new version.
+
+
+@section overview_backwardcompat_sourcecompat Source Level Compatibility
+
+Later releases from a stable branch are backward compatible with earlier
+releases from the same branch at the source level. This means that, for
+example, if you develop your application using wxWidgets 2.8.0 then it should
+also compile fine with all later 2.8.x versions.
+
+The converse is also true providing you avoid any new features not present in
+the earlier version. For example if you develop using 2.6.1 your program will
+compile fine with wxWidgets 2.8.0 providing you don't use any 2.8.1 specific
+features.
+
+For some platforms binary compatibility is also supported, see
+@ref overview_backwardcompat_libbincompat below.
+
+Between minor versions, for example between 2.4.x, 2.6.x and 2.8.x, there will
+be some incompatibilities. Wherever possible the old way of doing something is
+kept alongside the new for a time wrapped inside:
+
+@code
+#if WXWIN_COMPATIBILITY_2_6
+ // deprecated feature
+ ...
projects / wxWidgets.git / blobdiff