Guidelines and HOWTOs/Applications FAQ: Difference between revisions
(Created page with "__TOC__ 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...") |
(Mark for updating) |
||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Review|Check for outdated infformation.}} | |||
__TOC__ | __TOC__ | ||
We have collected here some recurrent questions about the KDE release process. | 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 | ==== When in dependency freeze, can I add - by the beta release date - new features which require no new dependencies? ==== | ||
Yes | 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? == | ==== 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 | 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? == | ==== 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. | 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? == | ==== 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 | 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? == | ==== 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. | 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? == | ==== 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 | New release branches are created by the release team. Run <code>git pull --all</code> to update your local repository. | ||
== Why do we need a week | ==== 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 | 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? == | ==== 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, | Because if beta and RC have important bugs, often not enough bug reports come in, because 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. | ||
Latest revision as of 10:21, 4 June 2019
Warning
This page needs a review and probably holds information that needs to be fixed.
Parts to be reviewed:
Check for outdated infformation.
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 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, often not enough bug reports come in, because 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.