kicad-lib-committers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Hi Carl

So what is the exact plan here?

I personally don't see the big issue with updating schematic libs and
the recovery fires. That is why we have the recovery. I would rather
like us to get the libs updated such that people can actually use them
for something rather than hide it.

But when that is said I would like to see that there is no removals of
libs in the release tar made compared to the previous.

Wayne said he would call it a release during this weekend so I would
like a decision made fairly soon :)

Regards
Nick Østergaard

p.s.
Below is some discussion we had with the 4.0.2 release where we reused
the libs becasue of the time.

2016-02-23 23:47 GMT+01:00 Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>:
>
>
> On Fri, Feb 19, 2016 at 11:57 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
>>
>> I just checked and the library has been tagged with 4.0.2 but there were
>> changes to device.lib since 4.0.1.  It looks like the POT component was
>> resized which most likely will fire a component recovery for users who
>> have POTs in their schematics.  I think we should ship component
>> libraries that do not trigger a recovery during the 4 series stable
>> releases so it looks like you should pull the 4.0.1 library for
>> packaging for the remainder of version 4 stable releases.  I'll see if I
>> can come up with a reasonable policy to eliminate confusion in the
>> future.  We probably should just tag the library at X.0.0 when the
>> stable version is released and use that for the entire stable release
>> series to prevent any surprises for the user.  The other option is to
>> create separate library packages and let the user assume the risk when
>> updating the libraries.
>
>
>
> I'm in favor of using a single library tag for an entire Stable release
> series. For me the only acceptable changes, as is the case for software, is
> if a component was wrong and later fixed. As in the case of software, any
> fixes to erroneous components must be done via a branch and patch.
> Due to the large number of files and rapid additions and changes, this
> quickly becomes a nightmare unless someone wants to create a meta-repository
> to pull in *all* tagged libraries and then only update components which have
> been fixed.
>
> - Cirilo
>
>
>>
>>
>> On 2/19/2016 1:39 AM, Nick Østergaard wrote:
>> > I need a clear answer. If we don't want to update, then we shall move
>> > the tag on the libs to the 4.0.1 tag on the libs.
>> >
>> > 2016-02-15 19:36 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>> >> I'm not sure how much of a difference it makes with the github
>> >> libraries
>> >> since the contents of the libraries can change even if you don't update
>> >> your fp-lib-table.  Shipping the updated fp-lib-table wont make any
>> >> difference unless the user chooses to copy the new one.  The schematic
>> >> libraries however are a different matter.  We should probably keep
>> >> those
>> >> the same through out the entire stable 4 release series rather than
>> >> breaking users schematics.  I know Chris's rescue code goes a long way
>> >> in mitigating this issue but I would still like to avoid users having
>> >> to
>> >> rescue a schematic during a stable release series.
>> >>
>> >> On 2/15/2016 1:29 PM, Carl Poirier wrote:
>> >>> The pretty repository with the old name still exists for as long as
>> >>> needed. My question is about having lib differences between bugfix
>> >>> releases. In this case, the fp-lib-table will be updated so that 4.0.3
>> >>> will use the renamed lib whereas 4.0.2 uses the old lib.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Carl
>> >>>
>> >>> On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard <oe.nick@xxxxxxxxx
>> >>> <mailto:oe.nick@xxxxxxxxx>> wrote:
>> >>>
>> >>>     2016-02-14 17:07 GMT+01:00 Carl Poirier <carl.poirier.2@xxxxxxxxx
>> >>>     <mailto:carl.poirier.2@xxxxxxxxx>>:
>> >>>     > We have some new libraries to add to the fp-lib-table and one to
>> >>> rename. If
>> >>>     > we do so now, when we'll be tagging 4.0.3, it will include the
>> >>> changes.
>> >>>     >
>> >>>     > Would this be permitted in such a release? If not, what about
>> >>> version 4.1?
>> >>>
>> >>>     I am not exactly sure, but what about we just do not perform the
>> >>>     rename (for the release), but just add the new ones, then there is
>> >>>     little change for the user to experience errors, or am I mistaken?
>> >>>
>> >>>     > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard
>> >>>     <oe.nick@xxxxxxxxx <mailto:oe.nick@xxxxxxxxx>> wrote:
>> >>>     >>
>> >>>     >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard <oe.nick@xxxxxxxxx
>> >>>     <mailto:oe.nick@xxxxxxxxx>>:
>> >>>     >> > Ok, so we tag the latest snapshot of the libraries as
>> >>> suggested
>> >>>     by the
>> >>>     >> > librarians, and will do the same with the docs to get the
>> >>>     latest fixes
<snip>