Difference between revisions of "Release:Packaging Guide"

From GIMP Developer Wiki
Jump to: navigation, search
m
Line 1: Line 1:
This is a draft of upcoming guide for GIMP packagers.
+
Being a small team, GIMP developers cannot provide builds for all operating systems and their variants out there. Moreover, there seems to be a demand for 3rd party builds that provide extra features not available in upstream GIMP releases.
  
What we expect from packagers:
+
This guide aims to establish better communication between GIMP developers and 3rd party packagers and provide the latter with our understanding what we consider a good packaging practice.
  
* if you provide unstable (Git master) builds of GIMP, it should be possible to install it alongside with stable GIMP release.
+
== Packaging As-Is ==
* if you patch GIMP for whatever reason (more plugins, behavior changes etc.), you should document it and make the list of changes publicly available.
+
 
 +
While it's possible to build GIMP without certain features and keep the list of dependencies low, we ask packagers to provide as complete builds as possible.
 +
 
 +
If you provide unstable (Git master) builds of GIMP, it should be possible to install it alongside with a stable GIMP release. This is because we make unstable releases for people who are eager to try new features and provide sensible bug reports, while using the stable release for actual daily work.
 +
 
 +
== Packaging With Source Code Changes ==
 +
 
 +
Some packagers are known to build GIMP with tweaks that change the behavior of GIMP or add/remove features. Users should be able to know what exactly they are getting. Therefore, we ask packagers to provide a list of changes for users.
 +
 
 +
Additionally, GPLv3 requires all source code changes to be published.
 +
 
 +
We recommend creating a page that would list changes (e.g. in an itemized list) and link to source code patches available as diff files on per-feature basis.
 +
 
 +
== Extensions ==
 +
 
 +
We cannot realistically check every 3rd party build out there, but we would appreciate a list of 3rd party extensions and plugins that you ship with your build to get an understanding, what's in demand by users. This helps us providing better out-of-box user experience.

Revision as of 13:49, 28 December 2015

Being a small team, GIMP developers cannot provide builds for all operating systems and their variants out there. Moreover, there seems to be a demand for 3rd party builds that provide extra features not available in upstream GIMP releases.

This guide aims to establish better communication between GIMP developers and 3rd party packagers and provide the latter with our understanding what we consider a good packaging practice.

Packaging As-Is

While it's possible to build GIMP without certain features and keep the list of dependencies low, we ask packagers to provide as complete builds as possible.

If you provide unstable (Git master) builds of GIMP, it should be possible to install it alongside with a stable GIMP release. This is because we make unstable releases for people who are eager to try new features and provide sensible bug reports, while using the stable release for actual daily work.

Packaging With Source Code Changes

Some packagers are known to build GIMP with tweaks that change the behavior of GIMP or add/remove features. Users should be able to know what exactly they are getting. Therefore, we ask packagers to provide a list of changes for users.

Additionally, GPLv3 requires all source code changes to be published.

We recommend creating a page that would list changes (e.g. in an itemized list) and link to source code patches available as diff files on per-feature basis.

Extensions

We cannot realistically check every 3rd party build out there, but we would appreciate a list of 3rd party extensions and plugins that you ship with your build to get an understanding, what's in demand by users. This helps us providing better out-of-box user experience.