Adopting the Linux/Firefox/Chrome release strategy

[Boudewijn Rempt]

Hi,

I've been thinking about this a lot over the past weeks, and I want to
propose a new release strategy because I don't think the current one
with a master branch and a stable branch is working.

There are at least the following current problems that I see:

* I need to make builds of both branches: stable builds and development
builds. This is more work than I can handle.

* People need to backport bug fixes to the stable branch. This is not
happening, and I cannot handle the backporting of fixes myself anymore.

* Backporting features that were based on master (like soft-proofing)
is pretty hard now.

* People are not building and testing the 3.0 branch -- everyone who
builds themselves is doing so on master.


What I want to propose is following other fast moving projects like
Linux kernel, Chrome or Firefox and have:

* All feature development done in dedicated feature branches. These
branches should be named like Nishant's branch: NAME/feature-description.

* A six week release schedule with:

** a merge window of two weeks after each release: every feature that
is ready can be merged in those two weeks. Outside those two weeks only
bug fixes go into master.

** A four week stabilization/translation window. This should be sufficient
to allow the translators to keep up and to fix any stability issues that
occur after a feature is merged.

* Numbering like this: 3.0.x until we have all features promised for
the 2015 kickstarter, then 3.1.x, until we have all features promised
for the 2016 kickstarter, then 3.2.x.

* A release procedure where we package the translations into the source
tarball, as discussed before; I can then fix my build scripts to build
from the source release instead of a git tag.


If there is a desire for a stable branch, then I think we should see
whether that desire is great enough for someone to step up and do what
Greg Kroah-Hartman does for Linux: someone who backports fixes, tests
them and publishes a krita-stable.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org