luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-09 19:06:15 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: Suggest that new APIs don’t have to be in GLib

Browse Source 
GLib can’t grow forever, so we should really only be accepting APIs
which are useful across a variety of projects and which couldn’t easily
live in a separate library.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This commit is contained in:
Philip Withnall 2023-05-24 16:33:22 +01:00
parent d608ceedb3
commit 5212171d0e
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
CONTRIBUTING.md
View File

@ -92,6 +92,13 @@ A common way to introduce new APIs or data types to GLib is to prototype them in
another code base for a while, to gain real-life experience with them before
they are imported into GLib and marked as stable.
Many APIs and features may be best implemented in another library, unless they
will be useful for a significant number of applications. GLib does not, and
cannot, grow its API surface forever. APIs which integrate well with existing
GLib API, or which extend it to allow it to be integrated better with other
libraries, are more likely to be accepted than self-contained new APIs or
features which can easily exist outside of GLib.
Each feature should also come fully documented, and with tests which approach
full branch coverage of the new code. GLib’s CI system generates code coverage
reports which are viewable for each merge request. See