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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp