|
|
| (15 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| == Releasing Extragear Software ==
| | {{Moved To Community}} |
| | |
| This page documents the steps to release KDE extragear software packages.
| |
| | |
| === Branching ===
| |
| | |
| Before you create a release, branch it off of master. The name should be "$MAJOR.$MINOR" or similar, i.e. "1.2". This branch will be called "stable branch" in the text below.
| |
| | |
| === Freezing ===
| |
| | |
| To prevent regressions early before a release, it is suggested to emplace a "feature-freeze". From this point on, no new features should be introduced to the stable branch.
| |
| | |
| Before a release, you'll need to give translators a notification about the upcoming new version. On the settings page on projects.kde.org of your repository, set the "stable i18n branch" to the stable branch. Then write an email about one month before the release or so to the translators at on KDE i18n-doc <[email protected]> . At this point, do not do any changes to translated strings, i.e. consider your branch to be "string-frozen". If you do need a string changed, ask the translators for a string-freeze exception. | |
| | |
| Note: The master branch and other feature branches will always be unfrozen, and any kind of strings or features can be changed/added.
| |
| | |
| === Versioning in source code and libraries ===
| |
| | |
| When you are ready to do a release, make sure the current HEAD in the stable branch has the correct version string set in its source code as well as the SOVERSION etc., to reflect what you want to release.
| |
| | |
| A good suggestion is to have something like this in your top-level CMakeLists.txt:
| |
| | |
| <source lang="cmake">
| |
| set(KGRAPHVIEWER_VERSION_MAJOR "2")
| |
| set(KGRAPHVIEWER_VERSION_MINOR "1")
| |
| set(KGRAPHVIEWER_VERSION_PATCH "90")
| |
| set(KGRAPHVIEWER_SOVERSION "${KGRAPHVIEWER_VERSION_MAJOR}")
| |
| set(KGRAPHVIEWER_LIB_VERSION "${KGRAPHVIEWER_VERSION_MAJOR}.${KGRAPHVIEWER_VERSION_MINOR}")
| |
| configure_file (config-kgraphviewer.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config-kgraphviewer.h )
| |
| | |
| #usage somewhere in cmake for a library:
| |
| set_target_properties(kgraphviewerlib PROPERTIES VERSION ${KGRAPHVIEWER_LIB_VERSION} SOVERSION ${KGRAPHVIEWER_SOVERSION} OUTPUT_NAME kgraphviewer )
| |
| </source>
| |
| | |
| The config-kgraphviewer.h looks like this:
| |
| | |
| <source lang="cpp">
| |
| /* config-kgraphviewer.h. Generated by cmake from config.-kgraphviewer.h.cmake */
| |
| | |
| #ifndef CONFIG_KGRAPHVIEWER_H
| |
| #define CONFIG_KGRAPHVIEWER_H
| |
| | |
| #include <kdeversion.h>
| |
| | |
| #define KGRAPHVIEWER_MAJOR_VERSION @KGRAPHVIEWER_VERSION_MAJOR@
| |
| #define KGRAPHVIEWER_MINOR_VERSION @KGRAPHVIEWER_VERSION_MINOR@
| |
| #define KGRAPHVIEWER_PATCH_VERSION @KGRAPHVIEWER_VERSION_PATCH@
| |
| | |
| #define KGRAPHVIEWER_VERSION_STR "@KGRAPHVIEWER_VERSION_MAJOR@.@KGRAPHVIEWER_VERSION_MINOR@.@KGRAPHVIEWER_VERSION_PATCH@"
| |
| | |
| #define KGRAPHVIEWER_VERSION KDE_MAKE_VERSION(@KGRAPHVIEWER_VERSION_MAJOR@, @KGRAPHVIEWER_VERSION_MINOR@, @KGRAPHVIEWER_VERSION_PATCH@)
| |
| | |
| #endif // CONFIG_KGRAPHVIEWER_H
| |
| </source>
| |
| | |
| Then you can include the generated config-kgraphviewer.h in e.g. your main.cpp and use the KGRAPHVIEWER_VERSION_STR define and similar. You can also install this file (useful for libraries to do feature-detection based on the version number).
| |
| | |
| === Tagging ===
| |
| | |
| Directly before the release, your create a git tag of the version you want to release out to the open. Use something like the following where the tag name includes the full version (including major, minor and patch level). Don't forget to push that tag!
| |
| | |
| <source lang="bash">
| |
| git tag -m "Tag release of version 1.2.0" v1.2.0
| |
| git push --tags
| |
| </source>
| |
| | |
| === Creating a Tarball ===
| |
| | |
| The kde:releaseme scripts help with that. See the config files and scripts in there for how to do that. If you create a new config for a not-yet-supported extragear software package, do commit it upstream. Creating the tarball is then done using e.g.:
| |
| | |
| <source lang="bash">
| |
| ./yourproject.rb --src ~/path/to/your/project/ --git-branch v1.2.0 -b stable -m 75 -p ssh -v 1.2.0
| |
| </source>
| |
| | |
| === Uploading the Tarball ===
| |
| | |
| Push the tarball to some publically accessible server and create a sysadmin ticket, asking for the tarball to be moved to the KDE FTP mirrors. Do include a sha256 sum of the created tarball.
| |
| | |
| === Announcing the Release ===
| |
| | |
| Once the sysadmins moved the tarball, you can announce the release. First, write a detailed blog post on a site that is aggregated on planet.kde.org. Then send a mail to [email protected], [email protected] and your project's mailing list(s). The mail can be short and link to the longer announcement blog post. | |
