Latest revision as of 13:33, 19 May 2023

Guidelines for creating a new framework

If you are creating a new framework, this checklist can help you get it done correctly:

Make sure it follows all the active policies
The above includes many important things, make sure to read all of it. E.g. it includes the often forgotten rule for installing translations
If it is created by splitting code from an existing repository, the new repository should be created by using a script to create a graft point
Run astyle-kdelibs or uncrustify-kf5 (both are part of kde-dev-scripts)
Ensure the module doesn't depend on deprecated or "portingAid" frameworks like kdelibs4support
Ensure the module is in frameworks on projects.kde.org (the source information is in the repo kde:sysadmin/repo-metadata), otherwise ask for it to be moved there (https://go.kde.org/systickets)
Make sure it has Gitlab CI set up
Add a new product for it on bugs.kde.org, which must be called frameworks-<name>
Create a README.md file
Finally when it's all ready, change the yaml file to say release: true. The release scripts will then pick it up automatically for the next KF release.

Template

The framework-template directory in the kdeexamples repository has a setup.sh script that generates a helpful skeleton framework that is a good starting point for creating a framework. For example, if you were creating the KConfig framework, you might run

./setup.sh KConfig ../../kconfig

then go to the newly created "kconfig" directory and start adding source files etc.

@@ Line 2: / Line 2: @@
 If you are creating a new framework, this checklist can help you get it done correctly:
-* ensure it follows http://community.kde.org/Frameworks/Policies (which includes buildsystem etc.)
-* If it is created by splitting code from an existing repository, the new repository should be created by using a script to create a graft point;
-* Run astyle-kdelibs;
 * Make sure it follows all the [[Frameworks/Policies|active policies]]
-* Ensure the module is in frameworks/ (in the projects.kde.org XML), otherwise ask for it to be moved there
+* The above includes many important things, make sure to read all of it. E.g. it includes the often forgotten [[Frameworks/Frameworks_Localization_Policy#KI18n_installation_code|rule for installing translations]]
-* Adjust kde-build-metadata - in particular, add it to the deps for frameworks/kf5umbrella
+* If it is created by splitting code from an existing repository, the new repository should be created by using a script to create a graft point
-* Get the job set up on build.kde.org and added to the http://build.kde.org/view/Frameworks/ view
+* Run astyle-kdelibs or uncrustify-kf5 (both are part of kde-dev-scripts)
-* Ensure it is green
+* Ensure the module doesn't depend on deprecated or "portingAid" frameworks like kdelibs4support
-* Add a new component for it on bugs.kde.org
+* Ensure the module is in frameworks on projects.kde.org (the source information is in the repo kde:sysadmin/repo-metadata), otherwise ask for it to be moved there (https://go.kde.org/systickets)
-* Add the repository to reviewboard.kde.org (by asking the sysadmins)
+* Make sure it has Gitlab CI set up
-* Add the module to the list in repo kde:sysadmin/release-tools, branch frameworks/5.0, file modules.git, or ask dfaure to add it.
+* Add a new product for it on bugs.kde.org, which must be called frameworks-<name>
+* Create a README.md file
+* Finally when it's all ready, change the yaml file to say release: true. The release scripts will then pick it up automatically for the next KF release.
 == Template ==