Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

On 1/24/2018 11:57 AM, Carsten Schoenert wrote:
> Hi,
> 
> Am 15.01.18 um 12:09 schrieb Rene Pöschl:
>> 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.
> 
> I'd like to ask here again if there is some agreement found for the
> versioning as I'm going, or better need to go into some final
> preparation for uploading the library related packages into Debian NEW.
> 
> In detail there are some new planned source packages related to KiCad
> applications which need to go through the NEW queue (and this will take
> some weeks! mostly).
> 
> As agreed with Jean-Samuel we will get probably the following packages
> which are also the basic for the daily build PPA.
> 
> kicad-symbols
> kicad-footprints
> kicad-templates
> kicad-packages3d (or kicad-3dmodels)
> 
> Once I uploaded one new package to NEW all other packages should have
> the same versioning layout. Currently I can use any version and also can
> change this as often I like, but once in the package is in NEW I'm fixed
> to the version I uploaded.
> 
> So based on the issue Rene has pointed to I currently work with
> 5.0.0~2018.01.23 and so on
> By using the tilde every version is less than without a tilde. Some
> examples.
> 
>> carsten@i5:~  $ dpkg --compare-versions 5.0.0-1 lt 5.0.0~2018.01-1 && echo 
>> first string is less than the second || echo latter is less than the first
>> latter is less than the first
>> carsten@i5:~  $ dpkg --compare-versions 5.0.0~2018.01.23-1 lt 5.0.0-1 && 
>> echo first string is less than the second || echo latter is less than the 
>> first
>> first string is less than the second
>> carsten@i5:~  $ dpkg --compare-versions 5.0.0-1 lt 5.0.0a-1 && echo first 
>> string is less than the second || echo latter is less than the first
>> first string is less than the second
>> carsten@i5:~  $ dpkg --compare-versions 5.0.0a-1 lt 5.0.0a+2018.02-1 && echo 
>> first string is less than the second || echo latter is less than the first
>> first string is less than the second
>> carsten@i5:~  $ dpkg --compare-versions 5.0-1 lt 5.0.0a-1 && echo first 
>> string is less than the second || echo latter is less than the first
>> first string is less than the second
> 
> So as long the tagged version will not start by 5.0 but with 5.0.0
> (based on the release version of KiCad 5) I'm currently save with my
> current used version. Even if a character is added to the version.
> But if the library people can now make a final decision would probably
> not only help me but other packagers too!
> 

Carsten,

I am planning on using the same version as the stable 4 branch starting
at 5.0.0 and updating in increments of 0.0.1.  I don't know that it
makes sense to do that with the libraries but I would at least expect
the initial stable release library tags to be 5.0.0 so they match.  That
should make life tolerable for package devs.

Cheers,

Wayne

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Carsten Schoenert]

Hi,

Am 15.01.18 um 12:09 schrieb Rene Pöschl:
> 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.

I'd like to ask here again if there is some agreement found for the
versioning as I'm going, or better need to go into some final
preparation for uploading the library related packages into Debian NEW.

In detail there are some new planned source packages related to KiCad
applications which need to go through the NEW queue (and this will take
some weeks! mostly).

As agreed with Jean-Samuel we will get probably the following packages
which are also the basic for the daily build PPA.

kicad-symbols
kicad-footprints
kicad-templates
kicad-packages3d (or kicad-3dmodels)

Once I uploaded one new package to NEW all other packages should have
the same versioning layout. Currently I can use any version and also can
change this as often I like, but once in the package is in NEW I'm fixed
to the version I uploaded.

So based on the issue Rene has pointed to I currently work with
5.0.0~2018.01.23 and so on
By using the tilde every version is less than without a tilde. Some
examples.

> carsten@i5:~  $ dpkg --compare-versions 5.0.0-1 lt 5.0.0~2018.01-1 && echo 
> first string is less than the second || echo latter is less than the first
> latter is less than the first
> carsten@i5:~  $ dpkg --compare-versions 5.0.0~2018.01.23-1 lt 5.0.0-1 && echo 
> first string is less than the second || echo latter is less than the first
> first string is less than the second
> carsten@i5:~  $ dpkg --compare-versions 5.0.0-1 lt 5.0.0a-1 && echo first 
> string is less than the second || echo latter is less than the first
> first string is less than the second
> carsten@i5:~  $ dpkg --compare-versions 5.0.0a-1 lt 5.0.0a+2018.02-1 && echo 
> first string is less than the second || echo latter is less than the first
> first string is less than the second
> carsten@i5:~  $ dpkg --compare-versions 5.0-1 lt 5.0.0a-1 && echo first 
> string is less than the second || echo latter is less than the first
> first string is less than the second

So as long the tagged version will not start by 5.0 but with 5.0.0
(based on the release version of KiCad 5) I'm currently save with my
current used version. Even if a character is added to the version.
But if the library people can now make a final decision would probably
not only help me but other packagers too!

-- 
Regards
Carsten Schoenert

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Maciej Suminski]

On 01/23/2018 06:18 PM, Matthijs Kooijman wrote:
[snip]> Automatically updating existing schematics when one of its
symbols moved
> to a different library would of course be awesome if that could happen
> as well. I also made a suggestion about that:
> 
>> One way I can imagine this works is to also include a "rename"
>> specification (perhaps similar to the current rename.json), which can be
>> used by KiCad to automatically migrate older symbol references. Or
>> perhaps the rescue dialog can be improved to look among other libraries
>> for a symbol with the same name and let the user choose between
>> relinking to such a symbol, or resueing one from the cache.

I guess updating schematics will not be a problem anymore with the new
file format when symbols are going to be embedded in the schematics
file. You would need to point to the new library and symbol only if you
want to update the symbol, but I doubt it is a common case.

Regards,
Orson

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

On 1/23/2018 2:18 PM, Vesa Solonen wrote:
> Matthijs Kooijman kirjoitti 23/01/18 klo 19:18:
>> Hi Wayne,
> 
>> I think upgrading the library list is the most important, since (in the
>> eyes of users) it is a fairly trivial change (in terms of what needs to
>> happen, not necessarily in terms of implementation) that is annoying to
>> do every time (remove all libraries and re-add all libraries, or compare
>> the list of libraries to the files to see if anything changes).
>>
>> Automatically updating existing schematics when one of its symbols moved
>> to a different library would of course be awesome if that could happen
>> as well. I also made a suggestion about that:
>>
>>> One way I can imagine this works is to also include a "rename"
>>> specification (perhaps similar to the current rename.json), which can be
>>> used by KiCad to automatically migrate older symbol references. Or
>>> perhaps the rescue dialog can be improved to look among other libraries
>>> for a symbol with the same name and let the user choose between
>>> relinking to such a symbol, or resueing one from the cache.
> 
> I've spent some time on this and it seems the way to go is using
> UUID/hash as object identifier. That takes care of versioning, provides
> fast and robust search, identification and archival (on object basis,
> independent of "library" or version control system). Please refer to
> Horizon EDA and LibrePCB implementation for details.
> 
> -Vesa
> 

I'm not opposed to this if we come up with a reasonable solution that
solves all of our requirements (project portability across platforms).
If we want to use hashes for symbol lookup, we need to make this
decision before I implement the new schematic and symbol library formats.

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Vesa Solonen]

Matthijs Kooijman kirjoitti 23/01/18 klo 19:18:
> Hi Wayne,

> I think upgrading the library list is the most important, since (in the
> eyes of users) it is a fairly trivial change (in terms of what needs to
> happen, not necessarily in terms of implementation) that is annoying to
> do every time (remove all libraries and re-add all libraries, or compare
> the list of libraries to the files to see if anything changes).
> 
> Automatically updating existing schematics when one of its symbols moved
> to a different library would of course be awesome if that could happen
> as well. I also made a suggestion about that:
> 
>> One way I can imagine this works is to also include a "rename"
>> specification (perhaps similar to the current rename.json), which can be
>> used by KiCad to automatically migrate older symbol references. Or
>> perhaps the rescue dialog can be improved to look among other libraries
>> for a symbol with the same name and let the user choose between
>> relinking to such a symbol, or resueing one from the cache.

I've spent some time on this and it seems the way to go is using
UUID/hash as object identifier. That takes care of versioning, provides
fast and robust search, identification and archival (on object basis,
independent of "library" or version control system). Please refer to
Horizon EDA and LibrePCB implementation for details.

-Vesa

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

On 1/23/2018 12:18 PM, Matthijs Kooijman wrote:
> Hi Wayne,
> 
>> This is not a trivial issue to fix.  I'm not sure there is a good answer
>> for this issue.
> It's certainly not trivial, but I believe a fix would not be terribly
> hard either.
> 
> Let me repeat my original proposal here:
> 
>> I can imagine that KiCad either gets a way to:
>>  1) include all libraries in a given directory (e.g.
>> /usr/share/kicad/something). This should be re-evaluated whenever
>> KiCad starts up, so there should be an explicit
>> "/usr/share/kicad/library/*.lib" entry in the table (or something
>> like that), as opposed to actually putting each library in the table
>> individually, or
>>  2) include a secondary library table from the normal one. Then any kicad
>> library package can ship such a secondary library table, and update
>> it to reflect the new list of libraries.
>>
>> I think these would apply to both symbols and footprints equally. Option
>> 2) seems more elegant and flexible to me. Both options should be able to
>> provide pretty seamless library upgrades for users (and can even be
>> extended to third party library collections, or a user's own libraries).
> 
> So far, you've only responded to this proposal itself by saying you
> don't want KiCad to decide what libraries to load, but, as I already
> pointed out in a previous reply, both of these options would be opt-in
> through an entry in the global library table (or something similar).
> 
> The above proposal only makes sure that the library list gets upgraded,
> not the actual schematics that point to any symbols that are now moved
> into another library.
> 
> I think upgrading the library list is the most important, since (in the
> eyes of users) it is a fairly trivial change (in terms of what needs to
> happen, not necessarily in terms of implementation) that is annoying to
> do every time (remove all libraries and re-add all libraries, or compare
> the list of libraries to the files to see if anything changes).
> 
> Automatically updating existing schematics when one of its symbols moved
> to a different library would of course be awesome if that could happen
> as well. I also made a suggestion about that:
> 
>> One way I can imagine this works is to also include a "rename"
>> specification (perhaps similar to the current rename.json), which can be
>> used by KiCad to automatically migrate older symbol references. Or
>> perhaps the rescue dialog can be improved to look among other libraries
>> for a symbol with the same name and let the user choose between
>> relinking to such a symbol, or resueing one from the cache.

If someone comes up with a reasonable patch for this, I'm not opposed to
it.  Obviously it wont happen until v6.

> 
> Gr.
> 
> Matthijs
> 

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne,

> This is not a trivial issue to fix.  I'm not sure there is a good answer
> for this issue.
It's certainly not trivial, but I believe a fix would not be terribly
hard either.

Let me repeat my original proposal here:

> I can imagine that KiCad either gets a way to:
>  1) include all libraries in a given directory (e.g.
> /usr/share/kicad/something). This should be re-evaluated whenever
> KiCad starts up, so there should be an explicit
> "/usr/share/kicad/library/*.lib" entry in the table (or something
> like that), as opposed to actually putting each library in the table
> individually, or
>  2) include a secondary library table from the normal one. Then any kicad
> library package can ship such a secondary library table, and update
> it to reflect the new list of libraries.
>
> I think these would apply to both symbols and footprints equally. Option
> 2) seems more elegant and flexible to me. Both options should be able to
> provide pretty seamless library upgrades for users (and can even be
> extended to third party library collections, or a user's own libraries).

So far, you've only responded to this proposal itself by saying you
don't want KiCad to decide what libraries to load, but, as I already
pointed out in a previous reply, both of these options would be opt-in
through an entry in the global library table (or something similar).

The above proposal only makes sure that the library list gets upgraded,
not the actual schematics that point to any symbols that are now moved
into another library.

I think upgrading the library list is the most important, since (in the
eyes of users) it is a fairly trivial change (in terms of what needs to
happen, not necessarily in terms of implementation) that is annoying to
do every time (remove all libraries and re-add all libraries, or compare
the list of libraries to the files to see if anything changes).

Automatically updating existing schematics when one of its symbols moved
to a different library would of course be awesome if that could happen
as well. I also made a suggestion about that:

> One way I can imagine this works is to also include a "rename"
> specification (perhaps similar to the current rename.json), which can be
> used by KiCad to automatically migrate older symbol references. Or
> perhaps the rescue dialog can be improved to look among other libraries
> for a symbol with the same name and let the user choose between
> relinking to such a symbol, or resueing one from the cache.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

On 1/23/2018 11:56 AM, Matthijs Kooijman wrote:
> Hi Wayne,
> 
>> I was not being sarcastic.  Here is what I meant:
> Thanks for clarifying.
> 
>> For stable version 5, the libraries should be tagged and used for all
>> stable 5 point releases (5.0.1, 5.0.2, ...).  Most corporate users
>> prefer consistency over having the latest libraries so installing the
>> next point release of kicad will not change the libraries.
> Ok. Then my proposal does not apply at all to these users, since their
> libraries are completely unchanged within the (e.g.) v5 release cycle.
> 
> My proposal *does* apply to users that:
>  1. Upgrade their libaries when upgrading from (e.g.) v5 to v6.

I agree, libraries should get updated for new stable release versions.
I think users expect this to happen.

>  2. Upgrade their libraries ("at their discretion") within the (e.g.) v5
>cycle.
> 
> Even though in both cases, it is certainly acceptable to have uses
> expect some disruption in their library organisation (e.g. symbols that
> changed in a non-compatible manner, moving pins around), it would also
> be nice if these upgrades could be as smooth as possible (removing the
> need to manually figure out what changes were made to the library
> filenames and what symbols were moved where).

This is not a trivial issue to fix.  I'm not sure there is a good answer
for this issue.

> 
> Also, users from #2 are also beta-testing library changes, which
> improves the libaries seem by the #1 users, which seems like an
> additional reason to make it easier to upgrade often.
> 
> Gr.
> 
> Matthijs
> 

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne,

> I was not being sarcastic.  Here is what I meant:
Thanks for clarifying.

> For stable version 5, the libraries should be tagged and used for all
> stable 5 point releases (5.0.1, 5.0.2, ...).  Most corporate users
> prefer consistency over having the latest libraries so installing the
> next point release of kicad will not change the libraries.
Ok. Then my proposal does not apply at all to these users, since their
libraries are completely unchanged within the (e.g.) v5 release cycle.

My proposal *does* apply to users that:
 1. Upgrade their libaries when upgrading from (e.g.) v5 to v6.
 2. Upgrade their libraries ("at their discretion") within the (e.g.) v5
   cycle.

Even though in both cases, it is certainly acceptable to have uses
expect some disruption in their library organisation (e.g. symbols that
changed in a non-compatible manner, moving pins around), it would also
be nice if these upgrades could be as smooth as possible (removing the
need to manually figure out what changes were made to the library
filenames and what symbols were moved where).

Also, users from #2 are also beta-testing library changes, which
improves the libaries seem by the #1 users, which seems like an
additional reason to make it easier to upgrade often.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

Mattijs

I was not being sarcastic.  Here is what I meant:

For stable version 5, the libraries should be tagged and used for all
stable 5 point releases (5.0.1, 5.0.2, ...).  Most corporate users
prefer consistency over having the latest libraries so installing the
next point release of kicad will not change the libraries.

We can also provide updated library packages periodically for users
(assuming our package devs want to do this) who don't want to use git to
keep up with library changes and don't mind the disruption of having
libraries change during a stable release series.  This would be at the
users discretion.

If this is what you are proposing, then we agree.  If not, then we don't
in which case I need to understand what you are proposing before I can
agree to it.

Cheers,

Wayne

On 1/23/2018 11:16 AM, Matthijs Kooijman wrote:
> Hi Wayne,
> 
 [Proposal to make library upgrades easier]
>>>
>>> As a user, 1% agree.
>>
>> Me too!  If users want to constantly update their libraries, that's
>> their choice but kicad installers should not be forcing this on users.
>> We should have a fixed set of libraries that are tagged for a release
>> series so users have consistent libraries to work with until the next
>> stable release.  I wouldn't be very happy if my libraries were
>> completely changed when I updated to a new point release of KiCad.
>> Users in corporate environments tend to value stability more than having
>> the latest libraries.
> 
> I'm not sure what you mean here.
>  - Do you actually mean you agree and think something like my proposal
>should be agreed?
>  - Do you think my proposal includes forcing users to upgrade more
>often? I am merely proposing to make upgrades easier *when* they
>happen. How often a user upgrades seems unrelated.
>  - Are you sarcastic and think this is an issue only for users that
>"constantly update their libraries"?
> 
> I suspect the latter is what you meant, and if so, I tend to disagree,
> since even if such an upgrade happens only rarely (e.g. corresponding
> with a KiCad majore release or Linux distribution upgrade), as a user I
> would still like to see the upgrade happens smoothly, without requiring
> manually rebuilding my entire library table.
> 
> Also, I (and probably others) am actually interested in getting the
> latest library versions, mostly to get new symbols and fixes for
> existing symbols. Of course, backward-incompatible changes are a
> hindrance here, but I think there has already been some talk to limit
> such changes, including library renames, to (for example) major release
> versions. I guess adding new libraries within one major release cycle
> would be non-disruptive, though, so that would still benefit from my
> proposal.
> 
> Gr.
> 
> Matthijs
> 

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne,

> > > [Proposal to make library upgrades easier]
> >
> > As a user, 1% agree.
>
> Me too!  If users want to constantly update their libraries, that's
> their choice but kicad installers should not be forcing this on users.
> We should have a fixed set of libraries that are tagged for a release
> series so users have consistent libraries to work with until the next
> stable release.  I wouldn't be very happy if my libraries were
> completely changed when I updated to a new point release of KiCad.
> Users in corporate environments tend to value stability more than having
> the latest libraries.

I'm not sure what you mean here.
 - Do you actually mean you agree and think something like my proposal
   should be agreed?
 - Do you think my proposal includes forcing users to upgrade more
   often? I am merely proposing to make upgrades easier *when* they
   happen. How often a user upgrades seems unrelated.
 - Are you sarcastic and think this is an issue only for users that
   "constantly update their libraries"?

I suspect the latter is what you meant, and if so, I tend to disagree,
since even if such an upgrade happens only rarely (e.g. corresponding
with a KiCad majore release or Linux distribution upgrade), as a user I
would still like to see the upgrade happens smoothly, without requiring
manually rebuilding my entire library table.

Also, I (and probably others) am actually interested in getting the
latest library versions, mostly to get new symbols and fixes for
existing symbols. Of course, backward-incompatible changes are a
hindrance here, but I think there has already been some talk to limit
such changes, including library renames, to (for example) major release
versions. I guess adding new libraries within one major release cycle
would be non-disruptive, though, so that would still benefit from my
proposal.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Maciej Sumiński]

On 01/17/2018 11:05 AM, Rene Pöschl wrote:
[snip]
> The reason for this not being able to be auto tested is that one
> can not really parse a datasheet automatically.

Minor off-topic: you may want to have a look at uConfig [1]. I do not
claim it is a perfect tool, as I doubt it is possible to easily
implement datasheet parser to extract pin information, but for me it
worked surprisingly well.

Cheers,
Orson

1. https://github.com/Robotips/uConfig



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Rene Pöschl]

On 17/01/18 10:03, Carsten Schoenert wrote:

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.

Well, it was (and is) difficult to follow what is happen on the side of
the libraries, at least this is my impression. Communication is motsly
done by the GitHub issue tracker (which I find horrible to use) and I
guess within the KiCad forum. That's o.k. so far. I just want to mention
it's not easy for new people and also for me as someone who is packaging
all that various stuff to get easy actual information about the work and
plans of the library people.

About 1.5 to 2 years ago there I started to work with KiCad most of the
time I have tried to research around the usage and modification on the
libraries. It's now much better but cut be even better. And that 'even
better' is just a small step in my eyes. Hopefully now it's a bit mor
clear what I've tried to say.


Issues are not ideal but they are the best tool we currently have.
The mailing list would not be the right place to discuss lib specific
topics as they are of no interest to the typical developer.
(They are of interest to users, lib maintainers and maybe packagers)
Getting user input is most easily done via the forum.

In the future we will make a short post on the mailing list if we
think a change does influence packagers. (If i remember correctly
oliver did that in the past as well. With the horrible search
function of the mailing list this is not easy to find out.)


...

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.

I think I know what you say and I don't want to blame anyone here. I
just want to bring the problems on top probably not only I've found.

What me often helps in such situations is to really try to look at
myself and my work like other would do. So, how does this all looks for
someone from outside? What would he expect to see or to find. Is the
work or the goal I try to get really useful for other people?

I know that is difficult but if it would be easy others would already
have done the work.

To get others peoples view they need to know that some feedback is
appropriated. And this brings the circle again to the communication.


We had an issue about this open for half a year.
We made regular inquires over at the info forum
where a lot of experienced users where asked for feedback.

And still some things have been missed.
Also a few manufacturers have already merged/changed name
since we defined our new lib setup.
(Microchip bought Atmel for example.)
This means that our MCU_Atmel* libs already required renaming.
(MCU libs are the only libs that include a manufacturer name.
For footprints it is worse because we allow manufacturer specific
footprints. These then include the manufacturer name in their name.)



...

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.

What ever that means in times of git. :-)
But I got that you mean. And I suspect the core library team won't do
any maintenance of the old stuff proactive. But wanted to raise the
question as I know that some users of Debian can't follow the two years
release circle and need to stay on older versions and than ask mostly by
the bugtracker (in Debian) about new updates for their old versions. But
I can't answer such questions without to know what upstream is thinking
about. Maybe the library team want's write a small statement about the
situation of the libraries/symbols for the older version?


Kicad version 4 had one combined repo for symbols and 3d models
(kicad-library) plus one repo per footprint lib. (the 100 *.pretty repos)

Kicad version 5 has four repos:
 - kicad-symbols
 - kicad-footprints
 - kicad-packages3d (plus support repo kicad-packages3d-source)
 - kicad-templates




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.

I disagree on that as from the source view there is no difference
between both. But yes, one (or even more) person(s) can't do here any
serious quality testing work due the current and increasing amount of
symbols. This can only be done by automatic testing and as the 

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Maciej,

> I can easily imagine a message saying: "Why do you guys modify my
> perfectly organized symbol library table when I update the libraries
> package? I have carefully picked the libraries that are useful to me, so
> I do not need to go through a long list when selecting components. Now I
> need to reorganize them again!".
> 
> Just saying that one size does not fit everyone. Perhaps there is a
> smarter solution in between, like a possibility to import/export
> sym-lib-table. This way one can easily update the official library list
> if needed, and otherwise the table is not touched.
This is pretty much what I proposed, namely to put an explicit entry in
the global list which says "Include all libraries in this dir", or
"Include all libraries in this external table". You can still remove
that entry and include individiual libraries, which will then stay just
like you configured them.

The alternative, which I think you're afraid I'm proposing would indeed
be to do some kind of magic transformations to a library table just
based on the paths of each library, and that does not seem a good idea
to me either.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Chris Pavlina]

On Wed, Jan 17, 2018 at 07:55:02AM +, Matthijs Kooijman wrote:
> Hi Wayne,
> 
> > KiCad should not be determining which libraries get loaded just because
> > our library layout gets more complex.  I would reject any design changed
> > that loaded libraries outside the users control.  Maybe I'm misreading
> > this but it kind of sounds like that to me.
> My proposal would indeed be to load libraries, without the user
> configuring each individual library. However, the user would configure
> the entire thing (e.g. "load *all* libraries from the default
> distribution") and can disable the entire thing (and load libraries
> individually) if he wants more control.
> 
> As a user, that is exactly the amount of control I want. I don't realy
> care about which official libraries are in my library list exactly, I
> just want all of them so I have the broadest choice in components and
> footprints.
> 
> Additionally, I don't really want to think about this when upgrading. If
> I upgrade the libraries package, I really want to still be able to just
> use all official libraries, without having to check after each upgrade
> if there is perhaps a new .lib file that was not there before (which, I
> think, involves removing them all and re-adding them as the easiest way
> to do that). Currently, if some symbols are split off into a new
> library, and I forget to check this, they will silently disappear from
> my choice of symbols, and I might not even realize this (and simply
> assume a symbol I am looking for does not exist yet).
> 
> Even if I wanted to go through the trouble of checking the library list
> on upgrades, I might not always actually realise that I've upgraded when
> using distribution packages that get upgraded as part of a bigger
> upgrade.
> 
> What I write here is how *I* would like to see things as a user. I can
> imagine this applies to more, if not most, users as well.

As a user, 1% agree.

> 
> 
> One additional caveat I recently realized: Even if you would
> automaticlaly update the list of libraries, you will additionally need
> to rename/remap some symbols, since symbol references include the
> library name in v5. One way I can imagine this works is to also include
> a "rename" specification (perhaps similar to the current rename.json),
> which can be used by KiCad to automatically migrate older symbol
> references. Or perhaps the rescue dialog can be improved to look among
> other libraries for a symbol with the same name and let the user choose
> between relinking to such a symbol, or resueing one from the cache.
> 
> Gr.
> 
> Matthijs



___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Maciej Sumiński]

Hi Matthijs,

On 01/17/2018 08:55 AM, Matthijs Kooijman wrote:
[snip]
> Additionally, I don't really want to think about this when upgrading. If
> I upgrade the libraries package, I really want to still be able to just
> use all official libraries, without having to check after each upgrade
> if there is perhaps a new .lib file that was not there before (which, I
> think, involves removing them all and re-adding them as the easiest way
> to do that). Currently, if some symbols are split off into a new
> library, and I forget to check this, they will silently disappear from
> my choice of symbols, and I might not even realize this (and simply
> assume a symbol I am looking for does not exist yet).
> 
> Even if I wanted to go through the trouble of checking the library list
> on upgrades, I might not always actually realise that I've upgraded when
> using distribution packages that get upgraded as part of a bigger
> upgrade.
> 
> What I write here is how *I* would like to see things as a user. I can
> imagine this applies to more, if not most, users as well.

I can easily imagine a message saying: "Why do you guys modify my
perfectly organized symbol library table when I update the libraries
package? I have carefully picked the libraries that are useful to me, so
I do not need to go through a long list when selecting components. Now I
need to reorganize them again!".

Just saying that one size does not fit everyone. Perhaps there is a
smarter solution in between, like a possibility to import/export
sym-lib-table. This way one can easily update the official library list
if needed, and otherwise the table is not touched.

Regards,
Orson

> One additional caveat I recently realized: Even if you would
> automaticlaly update the list of libraries, you will additionally need
> to rename/remap some symbols, since symbol references include the
> library name in v5. One way I can imagine this works is to also include
> a "rename" specification (perhaps similar to the current rename.json),
> which can be used by KiCad to automatically migrate older symbol
> references. Or perhaps the rescue dialog can be improved to look among
> other libraries for a symbol with the same name and let the user choose
> between relinking to such a symbol, or resueing one from the cache.
> 
> Gr.
> 
> Matthijs
> 
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne, Carsten,

On Mon, Jan 15, 2018 at 12:49:00PM -0500, Wayne Stambaugh wrote:
> I agree 100%.  Once we tag the v5 stable libraries, package devs should
> clone from that version for every v5 point release to prevent the issue
> you are describing.

I think there might be a misunderstanding here. Wayne, I think you're
saying that there should be a *single* "v5" that is shipped along with
5.x.x KiCad releases?

I think Carsten was suggesting to have regular library releases, but use
a "v5" tag in the version number to indicate that it is intended for use
with any KiCad 5.x.x version.

Also, your wording implies (to me) that you're assuming that the
libraries will be shipped along with the binary (which I guess makes
sense on a Windows-installer based system), but I'm pretty sure that
most Linux distros will want to put the libraries in separate packages,
which are separately upgraded from the main KiCad binaries.

I'm not sure if these misunderstandings really exist, but it seems
useful to point them out.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi Wayne,

> KiCad should not be determining which libraries get loaded just because
> our library layout gets more complex.  I would reject any design changed
> that loaded libraries outside the users control.  Maybe I'm misreading
> this but it kind of sounds like that to me.
My proposal would indeed be to load libraries, without the user
configuring each individual library. However, the user would configure
the entire thing (e.g. "load *all* libraries from the default
distribution") and can disable the entire thing (and load libraries
individually) if he wants more control.

As a user, that is exactly the amount of control I want. I don't realy
care about which official libraries are in my library list exactly, I
just want all of them so I have the broadest choice in components and
footprints.

Additionally, I don't really want to think about this when upgrading. If
I upgrade the libraries package, I really want to still be able to just
use all official libraries, without having to check after each upgrade
if there is perhaps a new .lib file that was not there before (which, I
think, involves removing them all and re-adding them as the easiest way
to do that). Currently, if some symbols are split off into a new
library, and I forget to check this, they will silently disappear from
my choice of symbols, and I might not even realize this (and simply
assume a symbol I am looking for does not exist yet).

Even if I wanted to go through the trouble of checking the library list
on upgrades, I might not always actually realise that I've upgraded when
using distribution packages that get upgraded as part of a bigger
upgrade.

What I write here is how *I* would like to see things as a user. I can
imagine this applies to more, if not most, users as well.


One additional caveat I recently realized: Even if you would
automaticlaly update the list of libraries, you will additionally need
to rename/remap some symbols, since symbol references include the
library name in v5. One way I can imagine this works is to also include
a "rename" specification (perhaps similar to the current rename.json),
which can be used by KiCad to automatically migrate older symbol
references. Or perhaps the rescue dialog can be improved to look among
other libraries for a symbol with the same name and let the user choose
between relinking to such a symbol, or resueing one from the cache.

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

Hey Carsten,

On 1/15/2018 11:14 AM, Carsten Schoenert wrote:
> Hello Wayne,
> 
> Am 15.01.2018 um 14:56 schrieb Wayne Stambaugh:
>> 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.
> 
> then add a prefix to the date based version like 'v5-2018-02'. That's a
> problem that is up the library team to decide which tag will be used.
> And that's why I asked about that.
> 
> And depended on that also why I've asked about backward compatibility,
> if the current development of libs isn't backwards compatible than you
> need some versioning schema at all for the various libraries. For me it
> was a big fail that some libraries have been modified within a major
> release! That's not really user and distro friendly and breaking user
> acceptance in a longterm. Pleas think about Olimex e.g. as a company
> that is using KiCad for their business. And I expect to not have to deal
> with some important changes inside the libraries I use for a *stable*
> release of software that will break my local work!
> 

I agree 100%.  Once we tag the v5 stable libraries, package devs should
clone from that version for every v5 point release to prevent the issue
you are describing.

Cheers,

Wayne

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

We should tag stable 5 for all of the library repos and that should be
used for *all* stable 5 releases.  Changing libraries during a stable
version series (5.0.0, 5.0.1, ...) doesn't make sense to me.  I don't
think users expect their libraries to change for bug fix releases of KiCad.

Any other versioning scenario would be for users who like to keep up
with the latest and greatest libs.  I don't know if our package devs
would want to deal with that kind of package churn.  I'm guessing most
users who want the latest and greatest libs would be using git rather
than packages.  None of this should slow down the library development.
You may have to put a hold on commits for a day or two until you get all
of the repos tagged but from that point on, library development should
be able to resume as normal.

On 1/15/2018 11:01 AM, Rene Pöschl wrote:
> The version number is not the real question here.
> We can tag the libs monthly to allow users more fine grained control
> over which
> version they want to use.
> One option to still have the release information is to add an additional
> tag
> (with the kicad version) to the monthly release that coincides with a kicad
> release.
> 
> Now comes the real question. If the library release is bound to the
> kicad release,
> are we limited in what we can do on the library side?
> This either results in a slow down of library development.
> (We would need to limit the changes allowed during a stable release cycle.
> Example no splitting of libs.)
> Or if we do not limit it, users might be surprised that their setup
> suddenly
> doesn't work any more. (As has happened with the last few version 4
> releases.)
> After all they updated kicad from one minor release to the next.
> (Why should they expect changes to the library?)
> 
> If we however decide to decouple the release cycles the users gain more
> flexibility.
> They are in charge as to what they want to update and when they want do
> to it.
> A user that does only want to get bug fixes might opt to keep the old
> lib version.
> Whereas another user might want to update the lib more often than the
> release
> cylce of kicad would allow.
> 
> To be clear, both use cases are possible even without a monthly packaged
> release.
> (But they require a separation of library and program packages.)
> The one where we allow an older lib with kicad does require that no
> installer
> does force a library update. (Example: Not possible for fedora users
> right now.)
> The later use-case is also possible without a monthly package. But it
> definitely
> is easier with it. Without a monthly tag it would be significantly harder.
> 
> In my mind the best option in the long run would be a kicad internal
> library
> update manager that allows the installation of a specific library version.
> But such a feature is in the far future. Now the question is: Why not
> use the
> linux package manager for this, until we have a solution that would also
> work
> for other operating systems?
> 
> 
> On 15/01/18 14:56, Wayne Stambaugh wrote:
>> 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 

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

On 1/15/2018 10:23 AM, Matthijs Kooijman wrote:
> Hi folks,
> 
>>> 3. What are the plans for providing coherent library names and the
>>> introducing new libraries?
>> 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.
> I had an idea on solving this. Not sure if this is the right place for
> this suggestion (since it probably requires code changes in KiCad), but
> it seems relevant enough. I can imagine that KiCad either gets a way to:
>  1) include all libraries in a given directory (e.g.
> /usr/share/kicad/something). This should be re-evaluated whenever
> KiCad starts up, so there should be an explicit
> "/usr/share/kicad/library/*.lib" entry in the table (or something
> like that), as opposed to actually putting each library in the table
> individually, or
>  2) include a secondary library table from the normal one. Then any kicad
> library package can ship such a secondary library table, and update
> it to reflect the new list of libraries.
> 
> I think these would apply to both symbols and footprints equally. Option
> 2) seems more elegant and flexible to me. Both options should be able to
> provide pretty seamless library upgrades for users (and can even be
> extended to third party library collections, or a user's own libraries).

KiCad should not be determining which libraries get loaded just because
our library layout gets more complex.  I would reject any design changed
that loaded libraries outside the users control.  Maybe I'm misreading
this but it kind of sounds like that to me.

> 
> Has something like this ever been considered before?
> 
> Gr.
> 
> Matthijs
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Rene Pöschl]

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 

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Carsten Schoenert]

Hello Wayne,

Am 15.01.2018 um 14:56 schrieb Wayne Stambaugh:
> 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.

then add a prefix to the date based version like 'v5-2018-02'. That's a
problem that is up the library team to decide which tag will be used.
And that's why I asked about that.

And depended on that also why I've asked about backward compatibility,
if the current development of libs isn't backwards compatible than you
need some versioning schema at all for the various libraries. For me it
was a big fail that some libraries have been modified within a major
release! That's not really user and distro friendly and breaking user
acceptance in a longterm. Pleas think about Olimex e.g. as a company
that is using KiCad for their business. And I expect to not have to deal
with some important changes inside the libraries I use for a *stable*
release of software that will break my local work!

-- 
Regards
Carsten Schoenert

___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Rene Pöschl]

The version number is not the real question here.
We can tag the libs monthly to allow users more fine grained control 
over which

version they want to use.
One option to still have the release information is to add an additional tag
(with the kicad version) to the monthly release that coincides with a kicad
release.

Now comes the real question. If the library release is bound to the 
kicad release,

are we limited in what we can do on the library side?
This either results in a slow down of library development.
(We would need to limit the changes allowed during a stable release cycle.
Example no splitting of libs.)
Or if we do not limit it, users might be surprised that their setup 
suddenly
doesn't work any more. (As has happened with the last few version 4 
releases.)

After all they updated kicad from one minor release to the next.
(Why should they expect changes to the library?)

If we however decide to decouple the release cycles the users gain more 
flexibility.
They are in charge as to what they want to update and when they want do 
to it.
A user that does only want to get bug fixes might opt to keep the old 
lib version.
Whereas another user might want to update the lib more often than the 
release

cylce of kicad would allow.

To be clear, both use cases are possible even without a monthly packaged 
release.

(But they require a separation of library and program packages.)
The one where we allow an older lib with kicad does require that no 
installer
does force a library update. (Example: Not possible for fedora users 
right now.)
The later use-case is also possible without a monthly package. But it 
definitely

is easier with it. Without a monthly tag it would be significantly harder.

In my mind the best option in the long run would be a kicad internal library
update manager that allows the installation of a specific library version.
But such a feature is in the far future. Now the question is: Why not 
use the
linux package manager for this, until we have a solution that would also 
work

for other operating systems?


On 15/01/18 14:56, Wayne Stambaugh wrote:

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 

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Matthijs Kooijman]

Hi folks,

> > 3. What are the plans for providing coherent library names and the
> > introducing new libraries?
> 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.
I had an idea on solving this. Not sure if this is the right place for
this suggestion (since it probably requires code changes in KiCad), but
it seems relevant enough. I can imagine that KiCad either gets a way to:
 1) include all libraries in a given directory (e.g.
/usr/share/kicad/something). This should be re-evaluated whenever
KiCad starts up, so there should be an explicit
"/usr/share/kicad/library/*.lib" entry in the table (or something
like that), as opposed to actually putting each library in the table
individually, or
 2) include a secondary library table from the normal one. Then any kicad
library package can ship such a secondary library table, and update
it to reflect the new list of libraries.

I think these would apply to both symbols and footprints equally. Option
2) seems more elegant and flexible to me. Both options should be able to
provide pretty seamless library upgrades for users (and can even be
extended to third party library collections, or a user's own libraries).

Has something like this ever been considered before?

Gr.

Matthijs


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Wayne Stambaugh]

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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Rene Pöschl]

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

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Nick Østergaard]

Den 15. jan. 2018 11.16 skrev "Carsten Schoenert" :

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.

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

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!


I am also quite interested in the strategy here, for all above points.



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


If people want to handcuff themselves by free will, they shall remember
that the key is not in their own belt.

In other words, if they want to use kicad stable 4.0.x they shall not
expect to be using the new libraries.


--
Regards
Carsten Schoenert

___
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

[Kicad-developers] Future plans on the KiCad library releases?

[Carsten Schoenert]

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.

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

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!

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

-- 
Regards
Carsten Schoenert

___
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