HACKING

===============================================================================

Developers:
===========

Do NOT commit to this module without permission from a maintainer;
see the MAINTAINERS file for who they are.  You should also discuss any
changes at:

https://github.com/jimevins/glabels/issues

See below for additional guidelines.


Translators:
============

Translation commits are always welcome. Please recognize any rules from
your local team of the GNOME Translation Project. You may add or change
the following files:

/po/*.po
/po/LINGUAS
/help/*/*.po
/help/Makefile.am

Please don't edit the file POTFILES.in without approval from a
maintainer.


===============================================================================


ROADMAP
=======

See the TODO file in this directory.


BRANCHES
========

gLabels will typically have 2 active branches: a stable branch and a
development branch.  A branch represents a series of releases with a
fixed major and minor version.  The minor version will be an even
number for a stable branch and will be an odd number for a development
branch.  For example the "2.2.5" release would be from a stable branch
and "2.3.5" would be a development release.

Stable branch
-------------

Some characteristics of a stable branch:

- Prerequisites are fixed for the lifetime of the branch.
- The primary purpose of releases within a branch is to fix bugs.
- Besides bug fixes, releases may also include new and updated translations,
  updated documentation, and new label templates.
- Generally, no new features will be introduced by a release within a
  stable branch unless it is necessary to fix a bug.  Such a fix should not
  introduce new prerequisites.
- Nor will code be refactored unless it is necessary to fix a bug.
- The Git branch will be named glabels_major_minor.  E.g. "glabels_2_2".

Unstable/development branch
---------------------------

Some characteristics of a development branch:

- Prerequisites are volatile and may change release to release.
- The primary purpose of releases is to introduce new features and
  get them in the hands of testers.
- Features and file formats may be volatile and change release to
  release.
- No attempt will be made to maintain backwards compatibility with
  development releases.
- The development branch is maintained in the Git master branch.