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 with 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, that is a new dependency anyway.

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 with 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 without any new dependencies before beta release?

Because people depend on unreleased versions of libraries and stuff and the release manager have to make sure distros can actually build things from tarballs. One week is the bare minimum it takes the release manager to try to build everything and eventually have luck chasing people to make sure their dependncies 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.