kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

On 15/01/18 11:16, Carsten Schoenert wrote:
> Hi,
>
> as the packaging for Debian will change as well for the next KiCad
> release I've some questions pointed to the contributors and admins of
> the libraries to be able to prepare the needed package transitions as
> also mentioned by Jean-Samuel.
>
> 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.
> 2. What are the planned version numbers?
> As the libraries are changing regularly and these changes are
> independent from some KiCad major version I guess the usage of the KiCad
> version model isn't sufficient here. Most other project use here a date
> as version. e.g 2018_01 or 2018-02-15
As we aim for a regular release cycle independent from the kicad cycle, 
using a date as the version number would make sense to me.
> 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.
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.)

Maybe we could also have special dates where such changes are allowed. 
(Example once or twice 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.)