Policies/Application Lifecycle/Draft: Difference between revisions

From KDE Community Wiki
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 21: Line 21:
Projects move into [https://projects.kde.org/api/v1/projects/kdereview kdereview] when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards.
Projects move into [https://projects.kde.org/api/v1/projects/kdereview kdereview] when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards.
* You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]
* You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]
* See the [https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist Sanity Checklist] for some of the elements people will review
* See the [[ReleasingExtragearSoftware|Sanity Checklist]] for some of the elements people will review
* E-mail [https://mail.kde.org/mailman/listinfo/kde-core-devel kde-core-devel] and other relevant mailing lists with details of your project
* E-mail [https://mail.kde.org/mailman/listinfo/kde-core-devel kde-core-devel] and other relevant mailing lists with details of your project and what the expected destination is for the repo
* Make fixes to issues people bring up
* Make fixes to issues people bring up or provide explanation why they are not (yet) fixed
* Wait at least two weeks in kdereview
* Wait at least two weeks in kdereview


Line 29: Line 29:
Your project is now active and can make beta or stable releases. Find the best home for your project based on contents and release process wanted.
Your project is now active and can make beta or stable releases. Find the best home for your project based on contents and release process wanted.
* After two weeks in kdereview you can move it in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], file a [http://sysadmin.kde.org/tickets Sysadmin ticket] if unsure.
* After two weeks in kdereview you can move it in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], file a [http://sysadmin.kde.org/tickets Sysadmin ticket] if unsure.
* These projects should depend only on stable released software or software known it will get a stable release before the project does. It may use unstable or unreleased software only as an optional build dependency.
* KDE Frameworks are programmer libararies
* KDE Frameworks are programmer libararies
** They have [[/Frameworks/Policies|strict quality requirements]]
** They have [[/Frameworks/Policies|strict quality requirements]]
** Get released monthly
** Get released monthly
** Ask on [https://mail.kde.org/mailman/listinfo/kde-frameworks-devel kde-frameworks-devel] if you want to be considered for inclusion
** Ask on [https://mail.kde.org/mailman/listinfo/kde-frameworks-devel kde-frameworks-devel] if you want to be considered for inclusion
** External version numbers are made by release dude, there are no stable branches
** Version numbers are made by release dude, there are no stable branches
* Plasma is a cross device work environment where trust is put on the users' capacity to best define her own workflow and preferences.
* Plasma is a cross device work environment where trust is put on the users' capacity to best define her own workflow and preferences.
** It is typically released 3 times a year
** It is typically released 3 times a year
** Projects released as part of Plasma must fit well together and be a useful part of the user's work experience.  
** Projects released as part of Plasma must fit well together and be a useful part of the user's work experience.  
** They would not be useful to users of other desktops.
** They would not be useful to users of other desktops.
** External version numbers and stable branches are made by release dude
** Version numbers and stable branches are made by release dude
** Ask on [https://mail.kde.org/mailman/listinfo/plasma-devel plasma-devel] for consideration of inclusion
** Ask on [https://mail.kde.org/mailman/listinfo/plasma-devel plasma-devel] for consideration of inclusion
* KDE Applications
* KDE Applications
** Are released typically 3 times a year en-mass
** Are released typically 3 times a year en-masse
** Includes a range of libraries, applications and developer tools
** Includes a range of libraries, applications and developer tools
** External version numbers and stable branches are made by release dude
** External version numbers (projects often have their own internal version numbering scheme) and stable branches are made by release dude
** Ask [https://mail.kde.org/mailman/listinfo/release-team release-team] or  [https://community.kde.org/Release_Team#Coordinator_List module coordinators] for inclusion
** Ask [https://mail.kde.org/mailman/listinfo/release-team release-team] or  [https://community.kde.org/Release_Team#Coordinator_List module coordinators] for inclusion
* Self Released
* Self Released - Many projects take care of their own release process
** Also called Extragear
** Also called Extragear
** Many projects make their own releases
** They can use whatever version number scheme they want and can release in their own timeframe
** They can use whatever version number scheme they want and can release in their own timeframe
** Use [https://cgit.kde.org/releaseme.git/ releaseme] to make releases, see [[https://techbase.kde.org/ReleasingExtragearSoftware|Releasing Extragear Software]
** Use [https://cgit.kde.org/releaseme.git/ releaseme] to make releases, see [https://techbase.kde.org/ReleasingExtragearSoftware Releasing Extragear Software]


= Unmaintained =
= Unmaintained =
If a project is no longer useful you can move it to unmaintained.
If a project is no longer useful you can move it to [https://projects.kde.org/api/v1/projects/unmaintained unmaintained].  It can move here from any stage in the lifecycle.


Consider suggesting to [Gardening|KDE Gardening team] to maintain it if there are still valid use cases.
Consider suggesting to [[Gardening|KDE Gardening team]] to maintain it if there are still valid use cases.


You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]
You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]
Projects can move back to playground if they are picked up for maintenance again.


= Translations =
= Translations =
All projects with user-visible strings must have translations.
All projects with user-visible strings must have translations.


Whenever moving projects between Git modules or when you make a new stable branch you must tell kde-i18n-doc to update the translation branches.
Whenever moving projects between Git modules or when you make a new stable branch you must tell [https://mail.kde.org/mailman/listinfo/kde-i18n-doc kde-i18n-doc] mailing list to update the translation branches.


See [[https://techbase.kde.org/Development/Tutorials/Localization/i18n i18n wiki pages]].
See [https://techbase.kde.org/Development/Tutorials/Localization/i18n i18n wiki pages].

Latest revision as of 09:52, 26 July 2017

KDE is a friendly community which hosts hundreds of projects. Any project which follows the KDE manifesto and KDE Vision is welcome to join us.

The term "application" is used here to mean any project hosted in KDE Git and includes programming libraries and development tools but not typically infrastructure tools or projects with other end product outputs.

playground

playground is a Git module for projects starting development

  • You will need a Git write account which needs a referral from another KDE contributor, see Get_a_Developer_Account
  • You will need to to ask sysadmin to create a module
  • Projects can start in scratch repos without asking for a repo, see Git KDE.org manual
  • Projects can make alpha releases and can put them on download.kde.org unstable
  • Projects can ask for translations for their master branch only

Incubator

Projects which started life outside of KDE are welcome to join us if you feel our community makes a good fit through the KDE Incubator.

  • The projects should follow the KDE Incubator process.
  • A sponsor will guide you through the process and check your project complies with the needs of the KDE community

kdereview

Projects move into kdereview when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards.

Releasing

Your project is now active and can make beta or stable releases. Find the best home for your project based on contents and release process wanted.

  • After two weeks in kdereview you can move it in repo-metadata, file a Sysadmin ticket if unsure.
  • These projects should depend only on stable released software or software known it will get a stable release before the project does. It may use unstable or unreleased software only as an optional build dependency.
  • KDE Frameworks are programmer libararies
  • Plasma is a cross device work environment where trust is put on the users' capacity to best define her own workflow and preferences.
    • It is typically released 3 times a year
    • Projects released as part of Plasma must fit well together and be a useful part of the user's work experience.
    • They would not be useful to users of other desktops.
    • Version numbers and stable branches are made by release dude
    • Ask on plasma-devel for consideration of inclusion
  • KDE Applications
    • Are released typically 3 times a year en-masse
    • Includes a range of libraries, applications and developer tools
    • External version numbers (projects often have their own internal version numbering scheme) and stable branches are made by release dude
    • Ask release-team or module coordinators for inclusion
  • Self Released - Many projects take care of their own release process

Unmaintained

If a project is no longer useful you can move it to unmaintained. It can move here from any stage in the lifecycle.

Consider suggesting to KDE Gardening team to maintain it if there are still valid use cases.

You can move your project in repo-metadata, see repo-metadata README or file a Sysadmin ticket asking for the move

Projects can move back to playground if they are picked up for maintenance again.

Translations

All projects with user-visible strings must have translations.

Whenever moving projects between Git modules or when you make a new stable branch you must tell kde-i18n-doc mailing list to update the translation branches.

See i18n wiki pages.