kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> Unless we are going to prohibit new features (new file formats, new tool
> framework for eeschema, etc.) from being merged into the dev branch
> until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> the dev branch, then I'm OK with this proposal.

This is essentially my proposal - limit dev branch changes to 5.1
features, uncontroversial maintenance and bugfixes.

If people want to work on features for 6 now, that can be done in
separate branches, and the onus for keeping it rebased onto the 5.1
changes is on them, rather than forcing the 5.1 workers to deal with
conflicts. Otherwise, whoever is working on 5.1 features like the
GTK3/GAL stuff and printing, will have to continually port their work
between the two branches.

If 5.1 changes are unlikely to be substantially affected by 6.0-facing
changes, then perhaps this limitation is not useful.

> There should be nothing in the 5.1 branch that is not also in the dev
> branch so everything in the 5.1 branch should be tested in the dev
> branch builds.

In theory, yes, but if fixes need to be manually ported as the
branches diverge, it's possible to fail to fix, or break in new ways,
one branch or the other. If a 5.1 branch exists in parallel to 6.0,
someone will have to take responsibility to ensure the appropriate
fixes are identified, ported and tested as needed. In the Linux world,
this is the unglamorous, arduous (and vital) job of the stable branch
maintainers.

I'm not against parallel branches if someone is willing to step up to
be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
nice new stuff dropping into the dev branch. However, changes that
need to be in both branches are not trivially rebasable, that job will
soon become decidedly not-fun.

Cheers,

John