I was always a fan of upgrades, but in the meantime I am more a follower of:
If you upgrade to this new version, please re-setup your whole wine configuration
and merge over your data.
This should only very seldom be the case anyway.
This causes less work for us and less work for the user due to
[CCd wine-devel as I think you meant it to go there originally]
Holly Bostick wrote:
Seems to me that whether or not 99% of users will forget is not your
responsibility as developers. Other than making very sure that users
know there is something to remember, further programming against the
There are a bunch of different ways we may want to upgrade the users
configuration:
- Changes to $WINEPREFIX (~/.wine), for example:
- Introducing faked DLL headers
- Improved drive detection
- Changing the way the registry is stored
- Adding stuff to the virtual Windows drive
-
Mike Hearn wrote:
There are a bunch of different ways we may want to upgrade the users
configuration:
- Changes to $WINEPREFIX (~/.wine), for example:
- Introducing faked DLL headers
- Improved drive detection
- Changing the way the registry is stored
- Adding stuff to the virtual
I'm not sure we should design this system on the assumption that we suck
and will probably blow things up. I don't know of any other programs
that use such a mechanism when upgrading!
Well, Service Packs on Windows have the option (on by default) to back up all
changed files just in case
On Tue, Sep 28, 2004 at 12:46:12PM +0100, Mike Hearn wrote:
There are a bunch of different ways we may want to upgrade the users
configuration:
I was always a fan of upgrades, but in the meantime I am more a follower of:
If you upgrade to this new version, please re-setup your whole wine
--- Mike Hearn [EMAIL PROTECTED] a écrit : On Thu, 2003-09-25 at
20:13, Sylvain Petreolle wrote:
Cant work, as 'make install' must be done being root user.
Good point. Possibly a timestamp key in the registry that is updated
with each alteration of winedefault.reg and is also updated in
On Thu, 2003-09-25 at 18:21, Alexandre Julliard wrote:
No, that hardcoded list is only for dlls that we know will never work
as native. We don't want to have to change it every week depending on
the progress of some other dll. There are plenty of things that you
may have to add in the registry
