kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

On 15/01/18 17:53, Carsten Schoenert wrote:
> Am 15.01.2018 um 12:09 schrieb Rene Pöschl:
> ...
> > > 1. Is there some release time strategy planned?
> > > Are there any release dates planned for the newly created repositories
> > > and what are the planes for releasing updates of these.
> > The only discussion i know of was between me and oliver over at the
> > github repo for the download page:
> > https://github.com/KiCad/kicad.github.io/issues/15
> > There we suggested a monthly release. (We will start to tag all library
> > repos once a month) The "package" for the download site is currently
> > rebuild weekly.
> Doing a release monthly is fast enough, even every two months would be
> fully acceptable I think.

Faster releases motivate contributors.
Remember: Most contributors add new stuff. Bugfixes are mainly
done by the library team.

> > > 3. What are the plans for providing coherent library names and the
> > > introducing new libraries?
> > > In the release circle for KiCad 4 some libraries have been abandoned and
> > > have been moved over to new libraries without a upgrade path. That had
> > > produced some headaches for me as package maintainer due users have
> > > complained (correctly) their projects didn't worked after the package
> > > update. I worked around this by providing symlinks from the old library
> > > name to the new library name if possible.
> > > Please don't break existing user installations within one release circle!
> > We will try to limit such problems. But it might still happen that a
> > library will be split up into multiple libs if the library gets too large.
> > As the libs are seen as a separate package any way, users should already
> > be aware that updates might break stuff.
> I would hardly consider to not to do this within the current stable
> release circle of KiCad. At least as long some extra action on the user
> side is needed to get all the libraries in correct inclusion order and
> usage for the local work.
> Adding new libraries isn't that problematic as they are just 'new'.
> Removing a library is a thing that doesn't have to happen, never ever!

That is why it might be a good idea to uncouple the software and library
version cycle. If the lib has a separate cycle we can inform users over
changes more easily.
> > We could make some announcement if something like this happens, then
> > package maintainers can mark such packages as a "major" release. (Not
> > sure how this would be compatible to the date idea.)
> Well, we need to talk *now* about such things, we all need a plan for
> handling the lifetime of a stable release.
>
> Some more information about the current plans and doings in the library
> team would be a good thing! And please not only through the KiCad user
> forum. Please use also the KiCad website and/or the new GitHub site for
> the libraries you have created.

Not sure what you mean here. The new libs are not yet official. Once they
are we will make a blog post about them.

> > Maybe we could also have special dates where such changes are allowed.
> > (Example once or twice a year.)
> I'd suggest to go now through the libraries and rethink the names of
> them which may conflict in the future. For example I've seen a symbol
> library for Zigee, which is a protocol (and no hardware), the underlying
> stack is IEEE 802.15.4 which is bound to the physics. The referenced
> hardware is from TI a C2250 as QFN package which is also used for
> 6LoWPAN based transmissions. So I would suggest to rename this to
> IEEE_802154 or similar.

Believe me. No matter how long you think about the names you will never
find everything that you want to change at a later date. We discussed the
current new names for over half a year.

> > > 4. What about backward compatibility of the libraries?
> > > I don't follow the development of KiCad in a regularly way and
> > > especially not the development of the libraries, so maybe this question
> > > is answered in another place already. What can be done if people who
> > > need to stay on KiCad 4 (e.g. we can't provide KiCad 5 for Debian 8
> > > (Jessie) aka Old-Stable).
> > The kicad 5 libs are not guaranteed to be compatible with kicad 4. For
> > example we now allow the use of rounded rectangle and polygon pads in
> > footprints which are not understood by kicad 4. (Currently this already
> > affects a few libs. The majority of libs is still compatible to kicad 4.
> > But as time goes on the number of incompatible libs will grow.)
> I personally can live with this, for the future I would suggesting the
> development is happen in a own branch and do some merging into a release
> branch (prefixed v5?) after the libraries have been tested and reviewed
> enough, this would also give the possibility to create a branch for the
> old v4 versions if someone wants to maintain this. There never has to be
> rushing some new shiny elements into a release without some enough
> invest of testing. And like done in other projects a merge window with
> clear rules will help to keep a high quality on releases.
The libs for version 4 still live in their old repos ;).

As far as i know, no further version 4 release is planned.

We have already archived most of the old repos.


Another thing to consider:

It is hard to find what symbol/footprint is correct. Even if the contributor
states it worked for their project, a different pcb manufacturer might still
have problems with it. A symbol (or footprint) can be in the library for

years and nobody finds out that it is incorrect. (We found a few footprints

while reworking the libs, that where incorrect for the last 3 years.)

The library can not be compared to software in this regard.