ebojd Messages: 225 Registered: January 2007 Location: USA
Experienced Member
> Or will there be some easy mechanism how to import older
> settings into new version?
The programs which have provided this level of control typically have a mechanism which will copy the last versions config info to the new version the first time the new version is run -- signified by no config files for that version. So, this is a question of "bootstrapping". Another option is to ask the use if they want the defaults or to copy over the old config info. There can be annoyances/issues with doing either (such as should we override the UPPSRC and COMMON variables or keep the old ones... I'll write more on that if people are interested in that discussion which is likely to be rather long and tedious.
> I'm not sure if I do get you right and fully understand
> how the Upp should work and how applications build upon
> Upp should work to take advantage of this.
I can see it going either way. Should the application keep it's own version configuration tree,
For most cases I think that the latter will suffice because it allow the developer to (re)build the application against a specific version of the U++ source tree. From a users perspective they simply rebuild the applications when they update U++.
The real advantage of this for the developer is that they can build/test/maintain applications across multiple versions and recreate a clients configuration. Have you ever updated U++ to discover that one of the API's had changed and your code will no longer compile? I have... From the users perspective the program hast to be rebuilt if they want to use the new code anyway, so there should be no requirements beyond that from the user.
If we are going to pick this one apart, can anyone suggest a specific application so we can come up with some concrete examples?
Members
Pages
Help
Register
Login
Home
