Thinking about this again, I feel I should note for your awareness when it comes to packaging that the primary things I'm concerned about on upgrades are already-running daemons and existing playlist files.
I don't remember to what extent I tested this when I did the original porting work back in September, so I'm not positive either of these things is actually an issue, but both should be tested in the packaged version if possible (in case there's anything that can be done, or needs to be documented, at upgrade time there). If I recall my observations correctly, the Python-3-based client will not communicate correctly with the Python-2-based daemon. Whether this will just result in error messages, or potentially cause problems (e.g. corrupting the playlist and/or history file), I would have to re-test to be certain. As the daemon typically runs on a per-user basis, we can't restart it at package upgrade time, so this will probably need to be handled by a user-visible notice (e.g. NEWS entry). I could look into adding a client-launch-time check and notification about this on the upstream side, or even potentially an "automatically kill and re-launch the daemon if we've crossed the Python-versions boundary" behavior - but I'm a little reluctant to do so, partly because of my level of expertise with the language involved and partly because this is a one-time transition which I'd prefer not to carry an every-launch check for indefinitely. Still, if you have a strong preference in this regard, I can see what may be possible here - although that would increase the chance that we'd miss the start of the release freeze. I also remember being concerned about whether the updated daemon would correctly parse and handle an existing playlist file from the older daemon, or whether the file would need to be discarded across the upgrade, and I don't remember whether that concern turned out to be baseless or whether I specifically tested that scenario. I'll look for an opportunity to carry out such a test, but if you have access to disposable testing environments (e.g. VM snapshots), you might be in a better position to do so than I currently am. If it doesn't work seamlessly, that's not really catastrophic, since moosic playlist contents are ephemeral to begin with - but again, probably worth notifying the user about at upgrade time, so that the playlist file can be backed up prior to first launch of the new demon under a given user. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
