Am 07.02.25 um 08:17 schrieb Thomas Lamprecht: > 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, ...
I just thought that in the context of a major release, many plugins will need to adapt to the new underlying Debian environment and thus provide new versions in any case. Doing breaking changes outside of a major release bears bigger risk that users might miss new plugin versions (e.g. installed the plugin once without configuring/checking for updates later). With "full major release" which of the following do you mean: 1. deprecated in PVE N.x, dropped in PVE (N+1).x for the same x 2. deprecated in PVE N.x, still supported throughout PVE (N+1), dropped with PVE (N+2).0 We also lose a little flexibility about how we can do breaking changes: e.g. changing parameter order would require adding a new method, changing the existing one to be a wrapper and then dropping the wrapper at some point - not so bad I guess, but forces us to come up with new names for those methods. But I can see your point why a full APIAGE reset is bad and not doing any is fine by me. The opt-in env-var or similar for deprecation warnings seems like a good approach IMHO. Just need to communicate this properly to plugin authors if we add it. The deadline for a breaking change could then also be included in the warning message. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
