mirror of https://github.com/GNOME/gimp.git
devel-docs: removing files and contents moved to developer.gimp.org.
The milestone and libtool instructions were moved over, as well as "Maintainer" section text from the devel README.
This commit is contained in:
Jehan
parent
8ab38eb883
commit
0e8a52a9f5
|
|
@ -11,9 +11,7 @@ EXTRA_DIST = \
|
||||||
README.md \
|
README.md \
|
||||||
contexts.txt \
|
contexts.txt \
|
||||||
debug-plug-ins.txt \
|
debug-plug-ins.txt \
|
||||||
gitlab-milestones.txt \
|
|
||||||
includes.txt \
|
includes.txt \
|
||||||
libtool-instructions.txt \
|
|
||||||
parasites.txt \
|
parasites.txt \
|
||||||
release-howto.txt \
|
release-howto.txt \
|
||||||
tagging.txt \
|
tagging.txt \
|
||||||
|
|
|
||||||
|
|
@ -417,88 +417,6 @@ make you feel like developing on GIMP means developing for yourself.
|
||||||
|
|
||||||
### Core Contributors
|
### Core Contributors
|
||||||
|
|
||||||
### Maintainers
|
|
||||||
|
|
||||||
GIMP maintainers have a few more responsibilities, in particular
|
|
||||||
regarding releases and coordination.
|
|
||||||
|
|
||||||
Some of these duties include:
|
|
||||||
|
|
||||||
- setting the version of GIMP as well as the API version. This is
|
|
||||||
explained in [libtool-instructions.txt](libtool-instructions.txt).
|
|
||||||
- Making a release by followng accurately the process described in
|
|
||||||
[release-howto.txt](release-howto.txt).
|
|
||||||
- Managing dependencies: except for core projects (such as `babl` and
|
|
||||||
`GEGL`), we should stay as conservative as possible for the stable
|
|
||||||
branch (otherwise distributions might end up getting stuck providing
|
|
||||||
very old GIMP versions). On development builds, we should verify any
|
|
||||||
mandatory dependency is at the very least available in Debian testing
|
|
||||||
and MSYS2; we may be a bit more adventurous for optional dependencies
|
|
||||||
yet stay reasonable (a feature is not so useful if nobody can build
|
|
||||||
it). In any case, any dependency bump must be carefully weighed within
|
|
||||||
reason, especially when getting close to make the development branch
|
|
||||||
into the new stable branch. See also [os-support.txt](os-support.txt).
|
|
||||||
- Maintain [milestones](gitlab-milestones.txt).
|
|
||||||
- Maintain [NEWS](/NEWS) file. Any developer is actually encouraged to
|
|
||||||
update it when they do noteworthy changes, but this is the
|
|
||||||
maintainers' role to do the finale checks and make sure we don't miss
|
|
||||||
anything. The purpose of this rule is to make it as easy as possible
|
|
||||||
to make a GIMP release as looking in this file to write release notes
|
|
||||||
is much easier than reviewing hundreds of commits.
|
|
||||||
|
|
||||||
#### AppStream metadata
|
|
||||||
|
|
||||||
One of the requirement of a good release is to have a proper `<release>`
|
|
||||||
tag in the [AppStream metadata
|
|
||||||
file](desktop/org.gimp.GIMP.appdata.xml.in.in). This metadata is used by
|
|
||||||
various installers (e.g. GNOME Software, KDE Discover), software
|
|
||||||
websites (e.g. Flathub). Having good release info in particular will
|
|
||||||
help people know what happened on the last release, and also it will
|
|
||||||
have GIMP feature among the "recently updated" software list, when the
|
|
||||||
installer/website has such a section.
|
|
||||||
|
|
||||||
Moreover we use this data within GIMP itself where we feature recent
|
|
||||||
changes in the Welcome dialog after an update.
|
|
||||||
|
|
||||||
What you should take care of are the following points:
|
|
||||||
|
|
||||||
* For the general rules on AppStream format, please refer to its
|
|
||||||
[specifications](https://www.freedesktop.org/software/appstream/docs/).
|
|
||||||
* Native language text are translated if a tag name starts with `_`.
|
|
||||||
Therefore do not use `<p>` but `<_p>` in the source. Same for `<_li>`
|
|
||||||
instead of `<li>`. These will be transformed by our build system.
|
|
||||||
* It also means you should push the `<release>` text early to leave time
|
|
||||||
to translators.
|
|
||||||
* Since we use this data in GIMP itself, we stick to a specific
|
|
||||||
contents in a `<release>` tag. In particular, all `<release>` tags
|
|
||||||
must start with one or several `<_p>` paragraphs, followed by a `<ul>`
|
|
||||||
list.
|
|
||||||
* Make sure the `date` and `version` attributes are appropriate. When
|
|
||||||
the release date is still unknown, setting "TODO" is a good practice
|
|
||||||
as our CI will `grep TODO` on even micro versions and fail on them.
|
|
||||||
* We have a custom feature in GIMP: adding `demo` attributes to `<_li>`
|
|
||||||
points of the release will generate a feature tour (basically blinking
|
|
||||||
several pieces of GIMP in order).
|
|
||||||
The format is as follows:
|
|
||||||
- demo steps are comma-separated;
|
|
||||||
- each step are in the form `dockable:widget=value`. You could write
|
|
||||||
only `dockable` (which would blink the dockable), or
|
|
||||||
`dockable:widget` (which would only blink the specific widget).
|
|
||||||
The full form would not only blink the widget but also change its
|
|
||||||
value (only boolean and integer types are supported for now).
|
|
||||||
- dockable names can be found in `app/dialogs/dialogs.c`. Since they
|
|
||||||
all start with `gimp-`, writing the suffix or not is equivalent.
|
|
||||||
- the widget IDs will default to the associated property. If the
|
|
||||||
widget is not a propwidget, or you wish to create a specific ID,
|
|
||||||
`gimp_widget_set_identifier()` must have been set explicitly to
|
|
||||||
this widget.
|
|
||||||
- as a special case, tool buttons (in `toolbox:` dockable) IDs are
|
|
||||||
the action names, so you can just search in `Edit > Keyboard
|
|
||||||
Shortcuts` menu. These are usually of the form `tools-*` so the
|
|
||||||
short form without `tools-` is also accepted.
|
|
||||||
- spaces in this `demo` attribute are ignored which allows to
|
|
||||||
pretty-write the demo rules for better reading.
|
|
||||||
|
|
||||||
### Directory structure of GIMP source tree
|
### Directory structure of GIMP source tree
|
||||||
|
|
||||||
GIMP source tree can be divided into the main application, libraries, plug-ins,
|
GIMP source tree can be divided into the main application, libraries, plug-ins,
|
||||||
|
|
|
||||||
|
|
@ -1,71 +0,0 @@
|
||||||
gitlab-milestones.txt
|
|
||||||
-----------------------
|
|
||||||
|
|
||||||
This document describes how the GIMP project uses milestones in the
|
|
||||||
GNOME gitlab issue tracker found at:
|
|
||||||
https://gitlab.gnome.org/GNOME/gimp
|
|
||||||
|
|
||||||
|
|
||||||
Stable milestones
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
We will create one milestone per micro-point release, as well as one per
|
|
||||||
minor-point release. For instance, if GIMP 2.10 is the stable release
|
|
||||||
branch, we will have a `2.10.32` milestone as well as a `2.10`
|
|
||||||
milestone.
|
|
||||||
|
|
||||||
Add reports to the next micro-point milestone when you expect to
|
|
||||||
fix/implement the bug or feature in this time frame; add it to the
|
|
||||||
minor-point milestone if you expect (or hope) to fix/implement in one of
|
|
||||||
the stable release yet doubt if will happen in the next release.
|
|
||||||
|
|
||||||
When planifying a new release, a maintainer must create the next
|
|
||||||
micro-point milestone shortly before releasing and start moving any
|
|
||||||
still opened report which could not be solved to this new milestone. For
|
|
||||||
instance before releasing 2.10.32, create the milestone `2.10.34`, then
|
|
||||||
go through all opened reports in `2.10.32` and move them to `2.10.34`
|
|
||||||
(unless someone expects to fix some at the last minute). When closing a
|
|
||||||
milestone, it must not contain any opened report.
|
|
||||||
|
|
||||||
The `2.10.32` milestone will be closed when GIMP 2.10.32 was released.
|
|
||||||
The `2.10` milestone will be closed only when no point releases are
|
|
||||||
expected in the 2.10 branch anymore.
|
|
||||||
|
|
||||||
Reports that are fixed in the stable branch should have the relevant
|
|
||||||
stable milestone set. Usually such a fix is done in the development
|
|
||||||
branch and then cherry-picked to the stable branch.
|
|
||||||
|
|
||||||
|
|
||||||
Next stable milestone
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
Similar rules apply to the next stable branch, for instance `3.0`
|
|
||||||
minor-point milestone and individual `2.99.10` micro-point milestones.
|
|
||||||
|
|
||||||
Note that any new feature must always be implemented in the next
|
|
||||||
stable milestones first. Indeed we don't want regressions (new features
|
|
||||||
popping in a 2.10 version then disappearing in 3.0). Yet they may be
|
|
||||||
backported later if some developers are willing to work on it. When this
|
|
||||||
happen, the report's milestone may be updated to the first version which
|
|
||||||
gets the feature.
|
|
||||||
|
|
||||||
If you fix a bug or implement a feature request for a release, then
|
|
||||||
please make sure that the milestone is set accordingly. This allows us
|
|
||||||
to make a list of changes by looking at the resolved bugs on the
|
|
||||||
milestone.
|
|
||||||
|
|
||||||
|
|
||||||
Future milestone
|
|
||||||
----------------
|
|
||||||
|
|
||||||
The bugs/enhancement requests on the `Future` milestone are things that
|
|
||||||
the GIMP project eventually wants to include in a future version, but in
|
|
||||||
what version is not yet decided.
|
|
||||||
|
|
||||||
Note that "decision" is a fluid notion. Indeed it mostly means that
|
|
||||||
someone cared enough for it to implement it properly. Therefore all it
|
|
||||||
takes is one of the developers making a point to work on a feature in a
|
|
||||||
given time frame.
|
|
||||||
Within such logic, the `Future` milestone is really more of a way to
|
|
||||||
tell that an improvement is a good idea, hence we'd be happy to have it,
|
|
||||||
yet nobody took on the task.
|
|
||||||
|
|
@ -1,65 +0,0 @@
|
||||||
configure.ac libtool settings
|
|
||||||
=============================
|
|
||||||
|
|
||||||
This is a brief description of how the various version variables at the
|
|
||||||
top of configure.ac are to be set, including gimp_interface_age and
|
|
||||||
gimp_binary_age.
|
|
||||||
|
|
||||||
See the arithmetic under the "libtool versioning" comment heading in
|
|
||||||
configure.ac as a reference.
|
|
||||||
|
|
||||||
See https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
|
|
||||||
for definitions of libtool "current", "revision" and "age" numbers as
|
|
||||||
used below.
|
|
||||||
|
|
||||||
When making a release
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
(1) When making releases on the stable branch, set:
|
|
||||||
gimp_micro_version += 1;
|
|
||||||
gimp_interface_age += 1;
|
|
||||||
|
|
||||||
If gimp_binary_age is defined as a constant, set gimp_binary_age += 1;
|
|
||||||
else if gimp_binary_age is defined as an m4_eval(), leave it as it is.
|
|
||||||
|
|
||||||
The default gimp_binary_age m4_eval() expression auto-increments
|
|
||||||
itself.
|
|
||||||
|
|
||||||
(2) NEVER increment gimp_interface_age and gimp_binary_age by more than
|
|
||||||
1 at any time for whatever reason, or you will have to wear a brown
|
|
||||||
paper bag on your head to hide your face for the rest of your life. If
|
|
||||||
you increment gimp_interface_age by more than 1, then the libtool
|
|
||||||
"current" number is decremented which could result in incompatible
|
|
||||||
library interface with existing bin programs.
|
|
||||||
|
|
||||||
(3) If any functions have been added, set gimp_interface_age=0. This
|
|
||||||
will cause the "current" and "age" part of libtool version to bump
|
|
||||||
upwards, increasing the interface number the library implements while
|
|
||||||
keeping the minimum interface number supported the same as before
|
|
||||||
(i.e., backwards compatible ABI).
|
|
||||||
|
|
||||||
Example: In GIMP 2.8.10, with gimp_minor_version=8,
|
|
||||||
gimp_micro_version=10 and gimp_interface_age=10 (incremented by 1
|
|
||||||
for every micro release), current=800 and age=800, which means that
|
|
||||||
the libraries support interface numbers 0 through 800, and the
|
|
||||||
interface DID NOT change at all between GIMP 2.8.0 to GIMP 2.8.10.
|
|
||||||
|
|
||||||
Example: In GIMP 2.8.12, with gimp_minor_version=8,
|
|
||||||
gimp_micro_version=12 and gimp_interface_age=0, current=812 and
|
|
||||||
age=812, which means that the libraries support interface numbers 0
|
|
||||||
through 812, and the ABI interface DID change in backwards
|
|
||||||
compatible manner at the time gimp_interface_age was set to 0.
|
|
||||||
|
|
||||||
(4) If backwards compatibility was broken, set gimp_binary_age=0 and
|
|
||||||
gimp_interface_age=0. This will cause "age" part of libtool version to
|
|
||||||
be 0, increasing the minimum interface supported to "current" part of
|
|
||||||
libtool version, and making ABI backwards incompatible (the linker
|
|
||||||
will not be able to use these libraries with programs compiled to work
|
|
||||||
against older libraries.
|
|
||||||
|
|
||||||
Example: In GIMP 2.8.14, with gimp_minor_version=8,
|
|
||||||
gimp_micro_version=14, gimp_binary_age=0 and gimp_interface_age=0,
|
|
||||||
current=814 and age=0, which means that the libraries support
|
|
||||||
interface number 814 only, which tells libtool the ABI interface
|
|
||||||
changed in backwards incompatible manner at the time
|
|
||||||
gimp_binary_age was set to 0.
|
|
||||||
Loading…
Reference in New Issue