kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I though we were using version tags on the library repos that matched
the kicad stable release version to ensure that packagers would be able
to provide the same libraries.  I don't want a situation where each
packager uses different commits from the library repos to create
packages.  I don't think the date idea suggested is going to be reliable.

On 1/15/2018 6:09 AM, Rene Pöschl wrote:
> 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.)
> 
> _______________________________________________
> 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