Adopting the Linux/Firefox/Chrome release strategy

[Wolthera]

This is fine, but we really need a shared calender. I recall we started on
a google calender? I'd be fine with taking up maintenance for it.

Phabricator also has a calender app, but it seems to be incomplete yet, and
it looks like they are going to make it compatible with google calender in
the future: https://secure.phabricator.com/project/board/542/

On Wed, Jul 13, 2016 at 2:30 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> 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
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Wolthera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160713/d151e7b4/attachment.html>