← Back to team overview

kicad-developers team mailing list archive

Re: Future plans on the KiCad library releases?

 


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


References