Guidelines and HOWTOs/Applications FAQ

We have collected here some recurrent questions about the KDE release process.

When in dependency freeze, can I add - by the beta release date - new features which require no new dependencies?

Yes.

When in dependency freeze, can I add - by the beta release date - features which require no new build dependencies but require a new run-time dependency?

No. A run-time dependency is a new dependency.

Should my application strictly follow the version numbering used in KDE Applications or can I adopt my own versioning schema?

Application version numbering is up to you as app maintainer.

Should I always use the YY.MM.80 schema for beta releases and YY.MM.90 for release candidates?

Again, versioning is up to you, but having a .80/.90 at the end is more in line with what we do in the rest of apps.

After creation of new release YY.MM branches, why is master version changed to YY.(MM+4)-1.70? Shouldn't that version be YY.MM.80?

YY.(MM+4)-1.70 is the version in master, which will become YY.(MM+4).00 after YY.MM.00 release.

Is the new release branch for my application created by the release team or should I create it myself?

New release branches are created by the release team. Run a 'git pull --all' to update your local repository.

Why do we need a week with no new dependencies before beta release?

Because people depend on unreleased versions of libraries and stuff and the release manager has to make sure distributions can actually build from tarballs. One week is the bare minimum it takes the release manager to try to build everything and eventually contact people to make sure their dependencies are released.

Why do we need a week between the tag and release for the final release but don't need that for tagging and releasing beta and RC?

Because if beta and RC have important bugs, noone really cares, we can just fix them in final release. Having a week for people to actually find important bugs in final release and retagging the packages is much more important.