Am 06.02.25 um 15:56 schrieb Fiona Ebner: > There are no such strong reasons, but we didn't have such strong reasons > last time either (IIRC changing snapshot parameter for export for btrfs > or something like that). I thought we need to do that on any breaking > change? We do have a few queued up already for the next reset. Hence my > suggestion to do it for PVE 9 so plugin authors can adapt together with > adapting for the new Debian release.
Yeah, last time caused some more fall-out than I expected, I have reduced motivation to repeat that, especially as we grew quite a few more users and also some new external storage plugins. If nothing big comes up I'm fine with just keep increasing both VERSION and AGE in lock-step as needed. If that becomes painful we should rework our approach to be less sudden – we want short betas for $reasons, thus plugin author do not get a long heads-up there at all – like e.g. using a moving window to more gradually drop support for older versions, unlike a full reset, ideally defining which will be removed already earlier (most lenient would be a full major release, less might be fine, needs to be thought out). We could use those two also to decide for what to warn and for what to either output nothing or only very rarely some notice level log We might also need to get a bit more strict with how we handle API breaks, but as this is easier to adapt too as end-user are less likely to be affected, as in, our UI still works, breakage happens normally at an endpoint level instead of all or nothing like here with storage plugins, which means likely breaking PVE interfacing with such storages completely, which will not allow guests on those storages to run or backups to go through, ... _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
