Am 07.02.25 um 12:57 schrieb Thomas Lamprecht:
> Am 07.02.25 um 10:59 schrieb Fiona Ebner:
>> 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
>
> Not sure how much one needs to adapt here, our plugi
Am 07.02.25 um 10:59 schrieb Fiona Ebner:
> 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
Not sure how much one needs to adapt here, our plugins IIRC never
required any adaption just due to doing a
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
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
Am 06.02.25 um 15:39 schrieb Thomas Lamprecht:
> Am 06.02.25 um 15:05 schrieb Fiona Ebner:
>> Am 05.02.25 um 16:20 schrieb Max Carrara:
>>> On Wed Feb 5, 2025 at 12:17 PM CET, Wolfgang Bumiller wrote:
I don't think accidentally-public private helpers should be considered
part of the AP
Am 06.02.25 um 15:05 schrieb Fiona Ebner:
> Am 05.02.25 um 16:20 schrieb Max Carrara:
>> On Wed Feb 5, 2025 at 12:17 PM CET, Wolfgang Bumiller wrote:
>>> I don't think accidentally-public private helpers should be considered
>>> part of the API. We can just deprecate them immediately, remove them
>
Am 05.02.25 um 16:20 schrieb Max Carrara:
> On Wed Feb 5, 2025 at 12:17 PM CET, Wolfgang Bumiller wrote:
>> I don't think accidentally-public private helpers should be considered
>> part of the API. We can just deprecate them immediately, remove them
>> "soon". They aren't part of the `PVE::Storage
On Wed Feb 5, 2025 at 12:17 PM CET, Wolfgang Bumiller wrote:
> Overall thoughts - this is a bit much at once...
>
> 1) It doesn't build. The loader fails, claiming that `DirPlugin` is not
> derived from `PVE::Storage::Plugin`. Presumably because you only
> `require` it which does not set up the `@I
Overall thoughts - this is a bit much at once...
1) It doesn't build. The loader fails, claiming that `DirPlugin` is not
derived from `PVE::Storage::Plugin`. Presumably because you only
`require` it which does not set up the `@ISA`...
(Followed by a bunch of "Plugin 'foo' is already loaded" errors
RFC: Tighter API Control for Storage Plugins - v1
=
Since this has been cooking for a while I've decided to send this in as
an RFC in order to get some early feedback in.
Note that this is quite experimental and also a little more complex;
I'll try
10 matches
Mail list logo
