kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

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.

>> 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!

> 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.

> 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.

>> 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.

-- 
Regards
Carsten Schoenert