Difference between revisions of "Release:Packaging Guide"

From GIMP Developer Wiki
Jump to: navigation, search
Line 5: Line 5:
 
== Packaging As-Is ==
 
== 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.
+
* '''Provide as many stock features as possible.''' While you can build GIMP without certain features and keep the list of dependencies low, we ask packagers to provide as complete builds as possible. This is to make sure that users get all the features they see advertised in the user manual and various tutorials online.
  
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.
+
* '''Make unstable builds available alongside stable builds.''' 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 ==
+
== 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.
+
* '''Document and publish your changes for end-users.''' 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.
+
* '''Release patches that you applied to GIMP.''' Publishing changes to source code is a GPL requirement. We ask you to honor it.
  
 
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.
 
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 ==
+
== Packaging with 3rd Party 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.
+
* '''List the 3rd party plugins and scripts that you bundled with GIMP.''' We are interested to understand what kind of existing plugins that are not part of GIMP are in a high demand by users. We cannot realistically check every 3rd party build out there, so we would appreciate a list of 3rd party extensions and plugins that you ship with your build. This helps us providing better out-of-box user experience.

Revision as of 20:35, 6 June 2016

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

  • Provide as many stock features as possible. While you can build GIMP without certain features and keep the list of dependencies low, we ask packagers to provide as complete builds as possible. This is to make sure that users get all the features they see advertised in the user manual and various tutorials online.
  • Make unstable builds available alongside stable builds. 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

  • Document and publish your changes for end-users. 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.
  • Release patches that you applied to GIMP. Publishing changes to source code is a GPL requirement. We ask you to honor it.

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.

Packaging with 3rd Party Extensions

  • List the 3rd party plugins and scripts that you bundled with GIMP. We are interested to understand what kind of existing plugins that are not part of GIMP are in a high demand by users. We cannot realistically check every 3rd party build out there, so we would appreciate a list of 3rd party extensions and plugins that you ship with your build. This helps us providing better out-of-box user experience.