← Back to team overview

kicad-developers team mailing list archive

Re: Version 6 development planning

 

Figuring this out is a good idea.  Thanks for suggesting it, John!

My branch contains upgrades to the connectivity and netlisting system in
eeschema.
I have been resolving conflicts from time to time as I am able.
It may be a good idea to get it merged before too much work goes into
eeschema modern tool framework, since my code changes the behavior of some
tools.
On the other hand, most of my code is "under the hood" so I don't really
mind refactoring my stuff before merge in order to match whatever is the
status quo.

https://github.com/craftyjon/kicad/tree/bus_upgrades

-Jon

On Sat, Feb 9, 2019 at 6:45 AM John Beard <john.j.beard@xxxxxxxxx> wrote:

> Hi,
>
> I have a few questions about the plan of action for the start of the
> v6 development window. I feel that since the 5.1.0 bug list[1] is
> dwindling, there are probably a few people around who are just waiting
> for a green light on v6.
>
> So that they can organise any pending patches better, I'd like to ask
> about the plan for v6 development opening. As far as I am aware, we
> will need to juggle the following tasks:
>
> 1) Removal of legacy canvases and supporting code
> 2) Further surgery on eeschema w.r.t. modern tool framework
> 3) New symbol format work (hopefully relatively self-contained in the
> plugin architecture)
> 4) Merging of various completed features from people who have them
> stored up since before v5 release
> 5) Normal ongoing bug fixing and development in the background
>
> There order this happens in will be quite important - if the legacy
> removal/eeschema tooling happens first, the features might not merge
> cleanly, but at the same time, legacy brings its own ongoing technical
> debt. If we can set the order down before the v6 floodgates open, at
> least we can approach the incoming patches in a systematic way.
> Specifically, if a major legacy-based refactor is anticipated soon
> after v6 opens, people should expect major rebasing to be required for
> incoming features.
>
> I don't really have any personal preference, as I don't have patches
> that are both urgent and impractical to rebase if needed.
>
> Perhaps a cursory survey of the work people expect to merge after v6
> might be in order? Links to git branches, etc?
>
> Cheers,
>
> John
>
> [1]: https://launchpad.net/kicad/+milestone/5.1.0
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References