kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

I would pretty much vote to use the IMO more common naming scheme for major package versions:

kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)

...avoiding the ".v5" i've seen lately.

I believe there is less demand for different minor versions installed next to each other, however it would be a nice-to-have.
(So... a user-selectable configuration might help: $ kicad -c projectconfig.cfg)

Regards,

Clemens

On 2018-04-12 09:33, Strontium wrote:
> After considering my patch, what about the following proposal:
> 
> Just change the hard coded string in common.cpp (at around line 243) from:
> 
> cfgpath.AppendDir( wxT( "kicad" ) );
> 
> to
> 
> cfgpath.AppendDir( wxT( "kicad.v5" ) );
> 
> (or some other string)
> 
> Thats it.  Then Kicad Version 5 will have a unique configuration 
> directory that will not conflict with version 4.
> 
> If an end user wants to bring their kicad V4 configuration over to v5, 
> they just copy it themselves.  Otherwise it starts with a brand new 
> blank configuration.  Alternatively packaging might be able to copy it 
> over.  But i don't see any real need to do it for the user at that 
> stage.  Its just a complication.
> 
> Then when the development branch is forked, just rename this again to 
> something like:
> cfgpath.AppendDir( wxT( "kicad.v6dev" ) );
> 
> (or whatever).
> 
> Then an end user can have V4, V5 and a Nightly all on the same machine 
> and configurations won't conflict.
> 
> Anything more exotic can be deferred to V6 development.
> 
> Steven
> 
> 
> 
> 
> On 08/04/18 13:33, Carsten Schoenert wrote:
>> Am 07.04.18 um 17:34 schrieb Strontium:
>>> Attached is a patch for discussion only.
>>>
>>> Its the minimum change I could come up with to implement a unique
>>> version specific config directory.
>>>
>>> Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
>>> or Mac.
>>> And on Linux, etc it will change from "~/.config/kicad" to
>>> "~/somethingelse/kicad" which would work, but isn't a very friendly
>>> naming scheme.
>> Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
>> pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
>> $HOME/.local/share.
>>
>> I'm sure Windows and Mac have similar variables for the folders that
>> should contain the logical same content.
>>
>> The path to the KiCad user config must based on such variables plus the
>> preferred name for the config folder, so like kicad-5 (for KiCad5) and
>> kicad-6 (for future version KiCad6) and kicad-nightly (for devel
>> version). GTK is doing this for a long time.
>>
>>> $ find  ~/.config -type d -name gtk*
>>> /home/carsten/.config/gtk-3.0
>>> /home/carsten/.config/gtk-2.0
>> If KiCad will introduce some version specific user config and data
>> folders (which I appreciate to see) it will be needed to configured by
>> the build environment and not hard-coded in the binaries. The variables
>> can be overwritten with some additional value given while starting the
>> applications.
>>
>> e.g.
>> take the default folders
>> $ kicad
>>
>> override the setting for the default config etc.
>> $ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad
>>
> 
> 
> _______________________________________________
> 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
>