Adopting the Linux/Firefox/Chrome release strategy
Boudewijn Rempt
boud at valdyas.org
Wed Jul 13 12:30:15 UTC 2016
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
More information about the kimageshop
mailing list