Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask dpkg-vendor what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules has
derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
and further down an override for dh_gencontrol to fill in “substvars” as appropriate:
override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif
This fills in the appropriate variables in debian/control:
Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
${solaar:Desktop-Icon-Theme}
and
Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
${solaar:Gnome-Icon-Theme}
You can use the test in debian/rules to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.
Best Answer
After a month of seeking, I still didn't find suitable build system that could meet the needs of our team. So I had to combine a new one from the existing components. Here they are:
gitanddebuild; it can createdebian/changelogfrom commits, push tags for release)Aptly (repository for binary Debian packages);
Small amount of Python "middleware" code;
However, I learned a lot (thanks to Debian developers) from this thread. There are a couple of tools developed by the community that probably can help someone who reading this topic: