Heads up: 5.1.1 is near. I plan to tag on Sun. 14. April 20:00 CET #1724
Comments
|
A lot of v6 stuff has already gone in. I personally thought that v6 cycle had already started: https://github.com/KiCad/kicad-symbols/milestone/2?closed=1 |
|
Additions don't matter at all so we can ignore these. The enhancements are what we need to look at in detail. |
|
Additionally: v6 is not expected for at least another 2 years. Do you really want to not give users library updates for 2 whole years? |
|
I checked your list. two changes break compatibility. (without reason) One is on the edge but we can argue it is for the better: Thinks like #1671 or #1445 are the reason why i would like to continue offering updates for v5.1.x So we have two options going forward. Keep the lib stable on the master branch or have two branches like the source code guys have. (The 5.1 branch would only be allowed to get bugfixes. Any bugfix to master must also be applied on the 5.1 branch and vise versa. This will double the workload for us and i would guess travis support might be needed here.) My idea would have been to take this step once the new file format exists. As i guess at that point we really will start with v6 development (A lot of v6 topics really depend on how the file format will be implemented. Doing changes now will only mean that we might do them again once we know the exact feature set supported for v6) |
Not at all! I meant that I understood that there would be no more releases after v5.1 until v6 so I poked Evan to merge some of the v6 stuff that may would have been better to wait on. I do not agree personally with such a big big release cycle for many reasons. If we can provide intermediate improvements for the users I think it will be possitive but that requires a better git workflow then. The workflow has been studied for a while I think. Maybe having a look at git flow would give us an idea on how to organize the development but it would be unavoidable to get users confused and the collaboration process would become more complex. Maybe we should be more aggressive and allow more breaking changes. After all users can always keep or download a copy of old library versions and use them. |
|
We had a very unstable lib in v4 cycle. This lead to many problems for users. The devs did not want to allow any updates to the library for that reasons in the v5 cycle. I came up with the compromise of limiting the impact of changes to the library to be allowed to roll out enhancements. I do not really agree that we really need to be more lenient on what can come in. to be honest if i would have more time than we would be a lot stricter here! I feel users benefit from getting updates. But they benefit much more from stability where it matters. I also really fail to see the benefit of including such design breaking changes especially if they just fix some minor KLC issue. Most users couldn't care less about KLC compliance. (They however care about poject portability. They want to be able to update freely without needing to think about it. Which is absolutely understandable if you think about it. After all there is quite a bit of money involved if a pcb is messed up or if a user looses access to design data.) And yes as i said above we could branch away version 5. In theory we could then require every contribution that can go into v5 to be made on both branches. That is completely infeasable so we would need to limit the v5 branch to bugfixes only (no more enhancements and definitely no more additions to v5 which would be sad.) Even with two branches i would competely refreain from any reorganization attempt until v6 is near. And even for real v6 development there will need to be some restrictions. Every proposed change will need to be evaluated for how its benefits outway the downsides. I learned with the v4 to v5 transistion and especially from user feedback over at the forum that some of the changes made where unnecessary. There was for example no real need to change pitch->P. This made it much harder for users to simply update their projects to v5. If i am still head of the library when v6 comes out then i will require any such changes to be made much more carefully. (My original proposal had been much more conservative but it got a bit out of hand till the end.) Footnote: We don't even have enough manpower to handle contributions as it stands now. How would you expect we are able to handle double that workload? |
|
Once v6 is released, the need to keep symbol libraries unchanged to
prevent symbol rescuing will go away. The library symbols will be
embedded in the new schematic file format which means that even if the
symbol in the library changes, the symbol in the schematic will not nor
will there be any need to rescue. This should make the need to keep
symbol libraries stable during stable release series necessary.
…On 4/9/2019 7:55 AM, Rene Pöschl wrote:
We had a very unstable lib in v4 cycle. This lead to many problems for
users. The devs did not want to allow any updates to the library for
that reasons in the v5 cycle. I came up with the compromise of limiting
the impact of changes to the library to be allowed to roll out enhancements.
I do not really agree that we really need to be more lenient on what can
come in. to be honest if i would have more time than we would be a lot
stricter here! I feel users benefit from getting updates. But they
benefit much more from stability where it matters. I also really fail to
see the benefit of including such design breaking changes especially if
they just fix some minor KLC issue. Most users couldn't care less about
KLC compliance. (They however care about poject portability. They want
to be able to update freely without needing to think about it. Which is
absolutely understandable if you think about it. After all there is
quite a bit of money involved if a pcb is messed up or if a user looses
access to design data.)
------------------------------------------------------------------------
And yes as i said above we could branch away version 5. In theory we
could then require every contribution that can go into v5 to be made on
both branches. That is completely infeasable so we would need to limit
the v5 branch to bugfixes only (no more enhancements and definitely no
more additions to v5 which would be sad.)
Even with two branches i would competely refreain from any
reorganization attempt until v6 is near. And even for real v6
development there will need to be some restrictions. Every proposed
change will need to be evaluated for how its benefits outway the downsides.
I learned with the v4 to v5 transistion and especially from user
feedback over at the forum that some of the changes made where
unnecessary. There was for example no real need to change pitch->P. This
made it much harder for users to simply update their projects to v5. If
i am still head of the library when v6 comes out then i will require any
such changes to be made much more carefully. (My original proposal had
been much more conservative but it got a bit out of hand till the end.)
------------------------------------------------------------------------
Footnote: We don't even have enough manpower to handle contributions as
it stands now. How would you expect we are able to handle double that
workload?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1724 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmpsbSv5tkX5Y2OCFqq7l1BEyFEBW8ks5vfH-rgaJpZM4cith3>.
|
|
I agree that with the probosed v6 feature set there will be less of a need to be stable. i however still feel that users might not like it much if we reorganize the library structure every few month. So a balance will need to be struck even if kicad itself would allow for much more changes to the library. Edit clarification: This is a comment about how to proceed once we published v6.0. (A bit in the future) My opinion on the v5 cycle is already documented in my previous comment(s). The transition period from v5 to v6 will allow for minor reorganizations (also documented in my previous comment) |
|
This is true but handling large library reorganizations is a different
problem to fix that requiring a way to merge library tables. The symbol
rescue/broken symbol links problem will be resolved which I think is a
far more problematic issue for most users.
…On 4/9/2019 9:48 AM, Rene Pöschl wrote:
I agree that with the probosed v6 feature set there will be less of a
need to be stable. i however still feel that users might not like it
much if we reorganize the library structure every few month. So a
balance will need to be struck even if kicad itself would allow for much
more changes to the library.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1724 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmppY63Z9GnDRtnpoTOMzZsfRDQW4eks5vfJo-gaJpZM4cith3>.
|
|
Just had a thought. #1176 removed one library. It fixed sym-lib-table as well. Is the table change captured when the user downloaded a new, fresh version of KiCad? I expect so. So users that snag 5.1.1 and install the libraries that come with it are good. However, what about users that will update their libraries separately? If they download 5.1.1 but don't install the libraries or if they keep using 5.1.0 and update their libraries. The symbol table will get mismatched, right? I reported an issue on Launchpad that covered this, but I can't find it now. https://bugs.launchpad.net/kicad/+bug/1820305 is related as well, I think. Is this a problem we (librarians) need to avoid by doing something in the library before 5.1.1 is tagged? |
|
No library table changes require manual updates by the user right now. (Only the default table is updated. The one in your settings does not update with an updated version of kicad.) This means we will need to add this library back possibly with a dummy asset in it. (Assuming this lib was in 5.1.0) Edit: or revert that pull request. Which might really be the better option. |
|
I've found the time to reorganize the current milestones. I've assigned every merged PR that doesn't break compatibility to the new 5.1.1 milestone. There are merged PRs in milestone 6.0.0 that require your attention @poeschlr. I would love if you could go over those and judge if they must target 6.0.0 release or if they can be released under 5.1.1 even when those changes break compatibility. Please assign the correct milestone to those you think we can release in 5.1.1 so that we can evaluate what to do with the merged changes before sunday. About the merged changes, I see the following options here:
Finally, it would be interesting to know if there is going to be a 5.1.2 release so that we can manage the corresponding milestone and avoid merging breaking changes as we did this time thinking that there will be no other release before v6. Thanks! |
|
There will be many more releases on 5.1.x (As noted above i personally suspect v6 will be ready in two years at the earliest. But i could be wrong about that) The question however is when will the new file format be available as i would suggest we reduce v5 support at that point in time. (A true evaluation what we can do for the v6 release really only makes sense once we have details about the v6 file format capabilities.) My personal hope is that the file format is not left till the end but will come rather soon such that it can stabilize till the release. I think that the library team can then play a vital role in testing the feature set. (We might need to create scripts that transfer assets to the new file format depending on how powerful kicad internal tools are for this task.) |
|
Regarding your probosed solutions for requests that need reverting: I doubt that it is feasible to do anything other than throw away the part of these that violates the requrements. It might be possible to isolate parts of these that can go into a future release. (Example if a commit fixed up a symbol and moved it to a different lib then the part of the commit that fixed the symbol can go in.) I know someone invested time into them but with the current file format we can not really keep reorganization commits in a parallel branch and expect them to be of any use later on. (resolving such a merge conflict is more work then redoing the work from a fresh branch.) Again i am truly sorry that it had to come to this but i think it is for the better for everyone involved. How we proceed once v6 is open will need detailed planning. But that planning can really only start when we have a general idea of the feature set provided by v6. Meaning i will open a separate issue when the time is right for this. (Maybe that will also coincide with a possible move of library assets over to cern gitlab servers. Not sure if this plan mentioned at FOSDEM still stands.) |
|
Changing the library tables (adding and/or removing libraries) during a
stable release series is not a good idea as KiCad has no capability of
detecting changes between the users library table and the updated
installed library table. This means that any removed libraries will
generate a missing library error and any new libraries will be ignored.
I'm hoping we can do something about this during the v6 development
cycle. Until we can address this, we should avoid adding and removing
libraries during a stable release series.
…On 4/11/19 11:59 AM, evanshultz wrote:
Just had a thought. #1176
<#1176> removed one library.
It fixed sym-lib-table as well.
Is the table change captured when the user downloaded a new, fresh
version of KiCad? I expect so. So users that snag 5.1.1 and install the
libraries that come with it are good.
However, what about users that will update their libraries separately?
If they download 5.1.1 but don't install the libraries or if they keep
using 5.1.0 and update their libraries. The symbol table will get
mismatched, right?
I reported an issue on Launchpad that convered this, but I can't find it
now. https://bugs.launchpad.net/kicad/+bug/1820305 is related as well, I
think.
Is this a problem we (librarians) need to avoid by doing something in
the library before 5.1.1 is tagged?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1724 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFnmppB-EyARjjqkp4mfi3c5o9-Z7E0Kks5vf1vKgaJpZM4cith3>.
|
|
Adding new libs with new assets should not really be an issue as it basically just means that users do not get some additions if they do not manually add them. (This should however still be done carefully as it hinders sharing of projects that use such assets.) |
|
I reverted only the one pull request that deleted a lib. The other 3 have changed symbols in a design breaking way but i deemed their impact small enough for them to being allowed in. Please be more mindful about that in the future as we want to be able to provide users with updates while not breaking their projects. |
|
Summary of design breaking changes compared to 5.1.0: Pins have been moved, renumbered or removed in symbol:
Deleted or moved symbols (mostly the RF library which i deemed to be a bugfix.):
Full logs: |
|
@poeschlr I have read almost all comments above. Just want to add my opinion to this issue. I have made a kind of checklist of the idea/questions I have on this subject: 1- I agree that users will complain if we are breaking the library. Point 2 is my main question as a reviewer and I clearly expect we have to speak on this subject. I'm almost sure this will be a blocking point. Cheers, Edit: an alternative can be to froze the library content in all v5.1.x, and upgrade only when the minor number changes, i.e. when v5.2 will be released. This can be a good compromise maybe... |
|
2: We don't. We sadly would need to tell somebody who breaks compatibility that we can not accept it right now and that they either need to reduce the changes till they are acceptable and if this is not an option close the pull request and convert it into an issue. 3: enhancments are ok but only if they do not break compatibility! (no symbol renamings, no moving of pins -> Edit3: This rule is also not as strict as you might think. If there is a really good reason to do it then it outweighs the desire to keep the lib stable. Just be very careful where you allow it and where not. If you need to ask then it is probably better to err on the side of stability. To make this more clear: Travis complaining is not a good reason to break projects. There must be a major tangible usability improvement or even better a reduction of possible erors/confusions. Example: stacking GND pins reduces the changes of user error and can therefore be done. At least if it is combined with other improvements to the symbol. Don't go around and start stacking all gnd pins just because you have some time on your hand, we have much more important things to do that do not break user schematics.) 4: I want to avoid not giving users new stuff for two years. Why do you think it is more important to fix mionor KLC issues than giving users a better stable library? (That really is something i simply do not get. Bugfixes for real issues will always be accepted even if they break old schematics as they already broke them with the original asset. The discussion really is only about some minor optical only KLC issues. Edit: take note which 3 contributions i allowed in. The only one i reverted was one that deleted a library which definitely breaks everyones installation.) And library re-organizations really should not happen without a well thought out plan in place. They need to be discussed in detail beforehand and will rely heavily on the v6 feature set. So it really is too early to start planning for this. Edit2: One major example is our current policy of pins are on 100mil grid. If kicad v6 allows snapping to pins instead of only to the grid then we can drop this rule. Meaning it is absolutely unnecessary to fix symbols by moving their pins around just to get them on 100mil grid if they can not be included in the last version of kicad that needs this rule at all. |
I will reopen the PR for future merge on v6 cylce. Thanks! Maybe this is not the time and/or the place but I would like to just present a idea that may help librarians with the current situation. I think that libraries could play a more important role in the release cycle. For as long as I have known KiCad, release numbering has mainly focused on software features and has overlooked librarie features. Maybe a tighter collaboration between librarians and software developers could lead to a "smoother" and more "continuous" way of releasing KiCad. It is at least very impractical for us librarians to stall PRs that will sit for a couple of years before being released while we are unable to manage those in any other way due to manpower limitations. I am not trying to push anything upstream but maybe there could be a way to start a conversation with developers to change the release paradigm slightly to be able to create a schematic breaking release in between this moment in time and the two year long v6 expected release. Maybe not including a lot of changes in software but including all the features in the library that have been sitting and waiting for a bigger release cycle. Many users know that they will not get big software features until v6 release. They may choose to not update untill v6 or update to a v5 version that includes a preview of the changes in the lib so that they can be updating their designs before the big changes in software come. Thank you very much to everybody for their contributions and their work to make this possible. |
|
@poeschlr I share your position and I have already seen you have reverted only a single specific modification. I understand that many pull requests will not be blocked but contributors are still able to fix some KLC issues to enhance the library, so I'm confident we will not be blocked at all. I also share the position of @antoniovazquezblanco and two years is probably a very long time between two releases. Maybe it's possible to split the work in v6 and v7 with a new release every year (I haven't the answer). |
|
We are not the ones that define what the release cylce is. Also after v6 we have much more freedom on the library side as the new file format will give better guarantees for users. (The main reason v6 will again take long is exactly because of the new file format. I doubt such a huge change can be made by volunteers in less than that time. But then again i have not really looked at the sourcecode yet so i could be totally wrong about that. If you really want a definitive answer as to when we can expect v6 then head over to the mailing list and ask nicely. Take any answer given at such an early stage of development with a grain of salt. The 2 year estimate comes from my experience of v5 development.) |
I know that. I think that we all know that. If it makes sense for us librarians to make use of a breaking release in the not so long future of the 2 years estimate, my proposal would be to talk to the lead developers that define what a release cycle is, in order to find a solution to the standing PRs before that 2 year long wait. Again, this is just a proposal as a in between solution to break things or wait for two years and fix a lot of merge conflicts. Maybe this can inspire other solutions or ideas that would be more suitable for our case. What I was trying to say is that maybe not only software should define program versions. Maybe library can also influence that. If this is of no use or if you think this does not improve our workflow problems that is fine. This was just brainstorming. Thanks @poeschlr for providing some guidance to the rest of us. Maybe we should already close this thread and the corresponding milestone. |
|
To be honest keeping pull requests open for too long is just not an option. As stated above we might need to be more agressive here and request reverting breaking changes if something else can make it in or if there is nothing left then close the pull request tell the user we are truly sorry and document the changes including the pull request number in an issue. (The pull request would only be referenced for later documentation i highly doubt any use will come of such a damned pull request.) And i also highly doubt that any typical user will make such a contribution in the first place. Most contributions are for new things. So only a tiny fraction of pull reqest are in danger of falling under this rule. And only another small fraction will then really break something in a way that we really can not use anything from the contribution. |
|
Thanks @poeschlr agree with you, probably it's the best option we have. Agree also that most contribution are additions :) |
Announcement see: https://lists.launchpad.net/kicad-developers/msg40077.html
I will check the library for design breaking changes as soon as i get around to it. Hopefully nothing too bad came in.
If you guys have anything that you really want to get in then make sure it is done by sunday. (Plan for the time needed for somebody else to review your stuff.)
The text was updated successfully, but these errors were encountered: