KDE Applications Versioning: Difference between revisions

From KDE UserBase Wiki
mNo edit summary
(Add more detailed introduction about version numbers and emphasize that KDE Application number versioning is optional)
Line 1: Line 1:
{{Construction}}
{{Construction}}


For applications that have no own release schedule beside the release with the KDE Applications releases,
Every application has an application version number that regular has to be increased to distinguish different versions of the application (e.g., features, bug fixes). Not using different version numbers for different releases can lead to confusing about dialog and lower the quality of the bugs reported, as it is not clear which version is affected. When an application does not have its own release schedule but is released alongside with KDE Applications, there is also the version number of the corresponding  KDE Applications release.
it is sometimes forgotten to increase the application version.


This can lead to confusing version numbers in the about dialog and lower the quality of the bugs reported,
It is the maintainer's duty to take care of increasing the version number regularly for every release. Specifically, there are two possible ways to do that:
as it is not clear which version is really affected.


To make this easier, the release scripts will auto-update the following CMake variables in the toplevel CMakeLists.txt of all applications bundled in the KDE Applications release:
# Increase the version number by hand for each new release.
# Use the same version number as KDE Applications and let the release script update the version number.
 
In the following, we explain how to use the scripted version numbers from KDE Applications within an application.
The release scripts will auto-update the following CMake variables in the toplevel CMakeLists.txt of all applications bundled in the KDE Applications release:


  # KDE Application Version, managed by release script
  # KDE Application Version, managed by release script
Line 16: Line 18:
You can then use them to  define the version for your own application based on this.
You can then use them to  define the version for your own application based on this.


For example Kate will do in its CMakeLists.txt:
For example Kate defines in its CMakeLists.txt:


  set (KDE_APPLICATIONS_VERSION "${KDE_APPLICATIONS_VERSION_MAJOR}.${KDE_APPLICATIONS_VERSION_MINOR}.${KDE_APPLICATIONS_VERSION_MICRO}")
  set (KDE_APPLICATIONS_VERSION "${KDE_APPLICATIONS_VERSION_MAJOR}.${KDE_APPLICATIONS_VERSION_MINOR}.${KDE_APPLICATIONS_VERSION_MICRO}")

Revision as of 07:41, 20 July 2015

Under Construction

This is a new page, currently under construction!


Every application has an application version number that regular has to be increased to distinguish different versions of the application (e.g., features, bug fixes). Not using different version numbers for different releases can lead to confusing about dialog and lower the quality of the bugs reported, as it is not clear which version is affected. When an application does not have its own release schedule but is released alongside with KDE Applications, there is also the version number of the corresponding KDE Applications release.

It is the maintainer's duty to take care of increasing the version number regularly for every release. Specifically, there are two possible ways to do that:

  1. Increase the version number by hand for each new release.
  2. Use the same version number as KDE Applications and let the release script update the version number.

In the following, we explain how to use the scripted version numbers from KDE Applications within an application. The release scripts will auto-update the following CMake variables in the toplevel CMakeLists.txt of all applications bundled in the KDE Applications release:

# KDE Application Version, managed by release script
set (KDE_APPLICATIONS_VERSION_MAJOR "15")
set (KDE_APPLICATIONS_VERSION_MINOR "04")
set (KDE_APPLICATIONS_VERSION_MICRO "0")

You can then use them to define the version for your own application based on this.

For example Kate defines in its CMakeLists.txt:

set (KDE_APPLICATIONS_VERSION "${KDE_APPLICATIONS_VERSION_MAJOR}.${KDE_APPLICATIONS_VERSION_MINOR}.${KDE_APPLICATIONS_VERSION_MICRO}")

and then use this in the config.h.cmake:

#define KATE_VERSION "${KDE_APPLICATIONS_VERSION}"

This is then passed to the KAboutData:

   /**
    * construct about data for Kate
    */
   KAboutData aboutData(QStringLiteral("kate"), i18n("Kate"), QStringLiteral(KATE_VERSION),
                        i18n("Kate - Advanced Text Editor"), KAboutLicense::LGPL_V2,
                        i18n("(c) 2000-2014 The Kate Authors"), QString(), QStringLiteral("http://kate-editor.org"));

Beside using the full version, you could only use the patch release version ${KDE_APPLICATIONS_VERSION_MICRO} to suffix your own version if you don't want to do that manually for each patch release.