Guidelines and HOWTOs/Applications FAQ: Difference between revisions

From KDE Community Wiki
No edit summary
(Mark for updating)
 
(7 intermediate revisions by 2 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 with require no new dependencies? ====
==== 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, that is a new dependency anyway.
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? ====
Line 17: Line 19:
==== 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 with the rest of apps.
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? ====
Line 25: Line 27:
==== 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 a 'git pull --all' to update your local repository.
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 without any new dependencies before beta release? ====
==== 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 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.
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, 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.
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.