Fileformat version #191
Comments
|
FYI it is not the version header of the dcm file but the one of the lib file that is at fault. The new lib file format would allow longer pin numbers. As long as we do not use long pin numbers we can revert to the old 2.3 file format. I would advice to stick to this old format because otherwise it does limit our pool of contributors to the users of the most recent nightly builds. More details see the mailing list: https://lists.launchpad.net/kicad-developers/msg33339.html |
|
OK, so forget about the DCMs ;-) I still think that we can move forward here ... For example for me that would be very tedious, as I cannot simply edit a library with a recent KiCAD but have to either manually edit or use an old KiCAD ... + There is the question of the sorting. What do we do about that? Do we switch back and forth, depending on which version people use? EDIT/ADDITION: Plus that would basically mean we CANNOT USE the new features until then, because otherwise we can always run into version problems |
|
I would rather provide a tool like that one: KiCad/kicad-library-utils#202 Maybe we can even generate two packages one for v4 and one for v5 automatically on the download page (http://kicad-pcb.org/libraries/download/), by simply applying the tool and removing any incompatible symbol from the v4-packages? |
|
The problem is that contributors might not have a recent nightly. (By the way this includes me) If i edit an affected lib with my version of kicad it will wipe the dcm file. |
|
... and it will reshuffle all the lines in the lib-file, which makes PRs really hard to review, as you don't really see the addition in the DIFF any more ... really hard nut to crack, I'm not really sure how to proceed. I see both arguments, but am somehow tempted to do the cut for v5 now, because we specifically opened to repo for the v5 libraries, so I think it should be compatible and support the features of that? |
|
@poeschlr We really need to get a decision here, otherwise we might have to stall several PRs! |
|
I would like to weigh in on this. Is there any reason why we could not
make the v4 to v5 break using the old kicad-library repo? That way we
would not be limited with our v5 symbol libraries. At some point we
have to make a clean break. The old kicad-library repo seems like a
logical place to do it.
Cheers,
Wayne
…On 1/20/2018 12:09 PM, Jan W. Krieger wrote:
@poeschlr <https://github.com/poeschlr> We really need to get a decision
here, otherwise we might have to stall several PRs!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpnFJdDQCVsj-LWljFyAMije8fJ2vks5tMh2ugaJpZM4RlZJP>.
|
|
We already kind of did that break, by creating the new repo and bringing over only those symbols that conform to KLC and are of good quality (I think we didn't loose many and for sure no important ones). Doing that we declared the old repo deprecated already. |
|
I understand that but why make the effort to keep the new symbol
libraries backwards compatible? We do not do this for any of the other
kicad file formats so I'm trying to understand why we need to do this
with our symbol libraries.
…On 1/20/2018 1:23 PM, Jan W. Krieger wrote:
We already kind of did that break, by creating the new repo and bringing
over only those symbols that conform to KLC and are of good quality (I
think we didn't loose many and for sure no important ones). Doing that
we declared the old repo deprecated already.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpgEecc6I6h5F2svx-7jR9ejMXWCOks5tMi8sgaJpZM4RlZJP>.
|
|
@stambaughw would it be possible for the lib editor only to pump the lib version up to 2.4 if features of this version are used? (Meaning if there is at least one pin with a long pin number) @jkriege2 another benefit of keeping the lib version compatible with v4 or older nightlies is that it allows v4 users to benefit from the lib reorganization. I don't think the line ordering stuff is that much of a problem. |
|
I would be in favour of a clean cut as @stambaughw suggests ... anything else will lead to chaos (with varying extent) at some point. I think having a script that makes a local copy v4-compatible is a good thing, but keeping this lib v4-compatible will be very tedious! |
|
I am not against a break but i would like to see a good reason for it. If no symbol uses the features of the 2.4 lib version i really do not see a reason why we should break v4 compatibility. |
|
On 1/20/2018 1:31 PM, Rene Pöschl wrote:
@stambaughw <https://github.com/stambaughw> would it be possible for the
lib editor only to pump the lib version up to 2.4 if features of this
version are used?
We have never supported forward compatibility and I really don't want to
start now. Given that the symbol library file format is not going to be
around much longer, I would rather not add another level of complexity
to the existing parser/formatter.
@jkriege2 <https://github.com/jkriege2> another benefit of keeping the
lib version compatible with v4 or older nightlies is that it allows v4
users to benefit from the lib reorganization. I don't think the line
ordering stuff is that much of a problem.
I would really like to see the sym libs being v4 compatible if no good
reason for using the new lib format exists. (If we get symbols with
longer pin numbers then i would agree that we should use the new lib
format. Otherwise i would really prefer the 2.3 lib format.)
If you want to create symbols with 4 character pin name limitation, that
is fine by me but it seems like an unnecessary limitation give that most
v4 users will not have access to the new symbol libraries by default.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpnPA3JBPtrA_YasxYTTFkp86gUNUks5tMjDtgaJpZM4RlZJP>.
|
|
I can make pins with pin names longer then 4 in kicad stable. Are you sure it is the pin name and not the pin number? (example: see the stm32 lib in the version 4 library) |
|
Once v5 is released you will start getting more (possibly all) symbol
library contributions with the 2.4 file version. You will either have
to reject those or manually tweak them yourself to maintain v4
compatibility. If you are ok with the extra burden of doing this, than
I am not opposed. I just think that you are making extra work for
yourself for little net gain. At some point, there will be enough 2.4
files that v4 compatibility will become very difficult.
…On 1/20/2018 1:39 PM, Rene Pöschl wrote:
I am not against a break but i would like to see a good reason for it.
If no symbol uses the features of the 2.4 lib version i really do not
see a reason why we should break v4 compatibility.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpk__XBxCoC9MugJBFUhxyD5shDy1ks5tMjLRgaJpZM4RlZJP>.
|
|
Casual contributor on Windows OS weighing in: However, I also empathize with Rene as I use KiCad for my work so I must use the stable version until 5 is released. Is it possible for both stable and nightly to coexist on the same computer somehow or does nightly install over stable? I will still try to contribute either way. The important point for me was being made aware of this issue so I can mitigate the DCM wipe that occurs. |
|
Hi Stephanie,
On 1/20/2018 6:14 PM, Stephanie wrote:
Casual contributor on Windows OS weighing in:
Jan's option 2 makes the most developmental sense to me. More
importantly, regardless of which option is decided for moving forward,
please make this explicit on the repo as well as on
http://kicad-pcb.org/libraries/contribute/
I wasn't aware of the lib versions and was confused as to why the DCMs
kept getting wiped.
However, I also empathize with Rene as I use KiCad for my work so I must
use the stable version until 5 is released. Is it possible for both
stable and nightly to coexist on the same computer somehow or does
nightly install over stable?
Yes, there is nothing preventing you from use multiple versions of KiCad
on windows. You may have to make some adjustments to your environment
variables when switching between versions if you want to continue using
the old v4 libraries. I actually have the separate version of kicad
running on my windows systems, 4.0.7, 32 bit head, and a 64 bit debug
build of head.
…
I will still try to contribute either way. The important point for me
was being made aware of this issue so I can mitigate the DCM wipe that
occurs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpt8p9pGjobfjCwkqHqIGNYIp6nN_ks5tMnNNgaJpZM4RlZJP>.
|
|
Hi Wayne, |
|
The normal thing to do is to use the available features of git; designate a v4 branch and a v5 (or dev) branch. The v4 branch would always be compatible with v4, but will not be up to date. The v5/dev branch will be main one for new PRs. When KiCad v5 is released, the v5/latest branch is made the default, and the v4 branch kept as legacy. |
|
As said before, we basically have that, just not as branches in one repo, but as two repos:
the latter are already frozen/set deprecated, so we will keep them, but not accept any more additions to them. This way v4-repos are there and v5-repos will be ready once v5 is released. About the branches: Were you thinking of merging changes from the v5-branch into the v4-branch if they do not use the new file-format features? If yes: Who should manage that and make the necessary changes? Into which branch should people submit? How do we handle the problem that the branches willl get farther apart over time, so merging is getting much harder? Also there is the problem of different instruction sorting between v4 and v5/nightly, which will make merges between the branches very hard, when people submit with v4 in one and v5 in the other. |
|
If you choose a conventional git method that every other project uses instead of a weird "only invented here" thing, then there are well understood ways of managing branches.
Nope, definitely not, didn't say anything like that. Read what I said, not what you think I was thinking. |
|
The rationale for moving into new repos was to make a clean cut and clean up in the process. Remember the old repo kicad-library ALSO contained the 3D models. and we had a separate repo for every type of footprint (which is annoying because you cannot open a new repo easily if you need one in a PR). Now this is unified into 4 repos with a clean structure. Also in preparation for the upcoming (v6) new file format, this should make the transition easier. So I don't really see the conceptual difference between two repos and two banches (especially if you don't want to merge between them). Also I think v4-KiCAD with its GitHUB-download-plugis will not work with branches ...! |
|
You are a master at creating strawman arguments. Anyway, you asked us what we think, it seems you are only interested in telling us what you think! Rather than pretend to canvas opinion, it would be simpler if you just went ahead and made the change and let people deal with it. I will suspend my activity until v5 is officially released. |
|
@poeschlr @evanshultz @Shackmeister @SchrodingersGat What do you think on this and the arguments exchanged above? |
|
@bobc Then please make a detailed proposal of how we should proceed starting from NOW, keeping in mind the structure that already exists and what is required to keep v4 working and have repos working for v5. And maybe with an eye on how to implement and manage the new structure with the limited resources that we have. |
|
To get this to a close how about the following: The master branch can get contributions in any file format. If there is a regression from 2.4 down to 2.3 we know that there might be an issue with the dcm file. (Kicad does not give any warning that the original file is in an unsupported file format. This is why travis should send out a warning here.) I will create a separate v4 compatibility branch. I will revert the lib version once for that branch. That branch will then stay at that one version. (It is intended for v4 users who want to see what the future will bring. It should also ease updating to v5. They can already create new projects with that lib while staying at the stable release. This will make the remapping process easier for them once they switch over to v5.) |
|
Fine with me mostly (basically we get a teaser for v4-users?) ... only: then we should somewhere note down this layout, so people find what they are looking for. Also: If you don't want to make any more changes to that, maybe we can even put a tag on it with a speaking name! PS: Do you want to branch off from the current trunk (should be all 2.3 I think) before I merge one or several of the PRs above which will change the version back? |
|
About noting down: I will add a note to the webside. (The kicad library download page will then get a section about kicad v4 compatibility. This will explain the issues regarding the new lib and mention the compatibility branch/tag) Before i create this branch i want to at least see #112 fixed. (Footprint filters need to be updated to the new names. At least where this is automatically possible.) |
|
I'm on fixing the motorola PR (#200) now ... give me 30min. I think that should be in the v4-branch! |
|
I also plan on adding the ep size to all footprints that include an exposed pad. If i get this done by today i would also like to include this in that branch. In other words you have enough time to fix your motorola stuff. |
|
Great! |
|
Hey Stephanie,
The key variables are:
KICAD_PTEMPLATES is the template and default project file path.
KISYSMOD is the path to the local footprint libraries if you don't use
the github plugin.
KICAD_SYMBOL_DIR is the default path for the symbol libraries when using
the symbol library table in v5. This has no effect on v4.
KISYS3DMOD is the default path for 3D models.
You can see how these are defined in v5 by opening the "Preferences ->
Configure Paths" dialog and see where these variables are pointing. You
may have to tweak them by editing them to match your set up. On
windows, I keep my 4.0.7 installed in the standard location and my
development builds in the appropriate /mingw32 or /mingw64 paths on my
msys2 build and I do not have to change environment variables.
…On 1/20/2018 8:34 PM, Stephanie wrote:
Hi Wayne,
That's great to hear! Do you have pro-tips regarding your library
environment setup that may be helpful for me to adapt into a workflow
that works for my situation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpt_lhe39Ewp5rWDqeEoUoNIES-3Gks5tMpQggaJpZM4RlZJP>.
|
Dear all!
we currently have a small inconsistency with file-format version (see PR #175). Basically the new KiCAD nightlies give an increased version number in the DCM-files, which renders them unreadable in older KiCAD version (actually I don't really see the point of this version change, as the format did not change AFAIK). Also the new nightlies sort the entries in the LIB differently, so switching between versions leads to a lot of noise in the DIFFs.
We need to decide how to work with this, as these version changes will appear more often, if people start to use the nightlies to contribute to this lib. In the PR #175 all version were reverted to the old 2.3. This makes DCMs usable in old and new KiCAD, but people using KiCAD nightlies for contributing (which is actually the desired case, because these libs are meant for KiCAD v5, while for v4 we have the legacy libs), we will need to require them to use a text-editor to change the version, which might pose an obstacle to several people.
So I would propose one of the following options:
a) if someone reverts a version 2.4 -> 2.3 we ask him not to do so,
b) if someone updates 2.3 -> 2.4 (with all the resorting) that's fine
c) if someone leaves 2.3 in pleace that's fine too
What do you all think?
JAN
The text was updated successfully, but these errors were encountered: