Duplicity track creation

store-requests
1

We need the following tracks created for duplicity:

0.8.23 0.8.24 0.8.25

…Thanks, …Ken

2

Hello,

Duplicity has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have a few questions before casting my vote.

  1. What’s Duplicity’s release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream?
  2. I see here you’re requesting tracks for what looks like patch releases, which is an unusual usage for tracks. Is this intended? are patch versions incompatible among themselves, would a user have a good reason not to upgrade to 0.8.25 if they’re currently using 0.8.24 for example? (As a hunch/suggestion, I think you’d be better served by tracks for e.g. 0.7, 0.8, and subsequent minor versions but I’ll defer to your requirements and knowledge of the project).
  3. Is there some commitment from upstream on maintenance of old versions? e.g. is 0.7 still supported with security updates? will it continue to be supported now that 0.8 is out, and for how long? What will happen once 0.9 is out?
  4. Are new versions backwards-incompatible? meaning, if I was running 0.8.24 and try to install 0.8.25, will that just work, or do I need to migrate my data/configuration, or will things break horribly? How about trying to read 0.7-produced data with 0.8? or, looking ahead, will 0.9 be able to read and/or write 0.8 files?

Thanks!

  • Daniel
3
  1. What’s Duplicity’s release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream?

Roughly one release every 4-5 months.

  1. I see here you’re requesting tracks for what looks like patch releases, which is an unusual usage for tracks. Is this intended? are patch versions incompatible among themselves, would a user have a good reason not to upgrade to 0.8.25 if they’re currently using 0.8.24 for example? (As a hunch/suggestion, I think you’d be better served by tracks for e.g. 0.7, 0.8, and subsequent minor versions but I’ll defer to your requirements and knowledge of the project).

No, not patch releases, just minor version releases and bug fixes.

The main reason is to provide a way for snap users to downgrade to a previous version if something else foobars in the core20 snaps. You’ll notice the absence of 0.8.22 snaps. The core18 to core20 change broke a lot of things and I’m sure we’ll find more. I just want to be able to tell users to go back to 0.8.23 if 0.8.24 breaks. Tracks seemed to be the best way to handle this.

  1. Is there some commitment from upstream on maintenance of old versions? e.g. is 0.7 still supported with security updates? will it continue to be supported now that 0.8 is out, and for how long? What will happen once 0.9 is out?

0.7 went to EOL when Python 2.7 went to EOL. I am the upstream, and I tell my users to upgrade to the latest 0.8.x when they make bug reports. I no longer support pre-0.8 versions except 0.7.19.

0.9.0 will get a track of its own when it’s ready, when I get the time to actually develop and not chase snap packaging issues. 0.8 will probably be supported for a year or two after 0.9 goes live. After that it will go to maintenance only. No firm date for 0.9 is possible right now. 0.9 will be Python 3 only with a new storage plan that allows much larger backups to remote providers.

Are new versions backwards-incompatible? meaning, if I was running 0.8.24 and try to install 0.8.25, will that just work, or do I need to migrate my data/configuration, or will things break horribly? How about trying to read 0.7-produced data with 0.8? or, looking ahead, will 0.9 be able to read and/or write 0.8 files?

Yes, until 0.9, backwards compatibility will be maintained. Until then older versions can still recover data from pre-0.9 versions, and 0.9 will be able to read older backups, for a term to be decided.

We’ll need to keep the last 0.8.x track alive for quite a while.

…Thanks,

…Ken

4

Thanks for explaining. I would probably recommend keeping e.g. core20 builds in a higher-risk channel (edge, for example) and ask brave users to test there, whereas stable would contain something that is stable (heh), and in this case for example, the core20-based snap would not be promoted to stable until all the kinks are ironed out.

Otherwise, the problem with using tracks this way is that it completely sidesteps the automatic upgrade nature of snaps and will require manual intervention for users who chose a track for whichever reason, to get updated to another track or to latest, negating the auto-update benefit of snaps.

That said, I’m not opposed to this use of tracks if you feel it gives you better control of how the software is distributed to users, taking into account the possibility of snap packaging-related issues as you mentioned, so I’m +1 on granting the requested tracks here.

I’ll wait a few days for other @reviewers to chime in and check the votes tally at that point.

  • Daniel
5

+1 to these tracks for duplicity.

1 Like
6

Thanks for your patience! The 3 requested tracks have been created.

  • Daniel