kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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