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