Hello,
For future releases of the module and underlying .NET libraries, would it be possible to maintain backwards compatibility and, when not possible (technically or not), provide an UPGRADE file listing all compatibility breaks and how to fix them?
I maintain some scripts and modules relying on PSPKI for my company and for each release I have some incompatibilities that I have to trace down. Fixing them is even more complicated when the scripts are not centrally stored and executed instead directly on colleagues' workstations where they may not all have the same module version installed.
I understand this requires extra work for you and the module and libraries are provided without any warranty on backwards compatibility but it is more and more used in professional environments where long term compatibility is mandatory.
Best regards,
Jordan
Comments: Thanks for your answer. I completely understand that sometimes you have to deprecate legacy code or even break backwards compatibility. As long as it is properly documented somewhere (I think an UPGRADE file accompanying the module is better than just a blog post, but that's just my opinion) and it is done for valid reasons there is absolutely no problem with that of course. Regarding the last 3.2.5 release, I haven't had time yet to fully test all my scripts but I have at least one that is failing now while it worked before. I will post a dedicated issue for that problem to avoid mixing things up. I don't remember which version exactly (probably the 3.0 or 3.1) but I remember having to change some classes namespaces after upgrading to a previous version. Not a huge deal of course and easy to spot and fix but this was not documented in your blog post.
For future releases of the module and underlying .NET libraries, would it be possible to maintain backwards compatibility and, when not possible (technically or not), provide an UPGRADE file listing all compatibility breaks and how to fix them?
I maintain some scripts and modules relying on PSPKI for my company and for each release I have some incompatibilities that I have to trace down. Fixing them is even more complicated when the scripts are not centrally stored and executed instead directly on colleagues' workstations where they may not all have the same module version installed.
I understand this requires extra work for you and the module and libraries are provided without any warranty on backwards compatibility but it is more and more used in professional environments where long term compatibility is mandatory.
Best regards,
Jordan
Comments: Thanks for your answer. I completely understand that sometimes you have to deprecate legacy code or even break backwards compatibility. As long as it is properly documented somewhere (I think an UPGRADE file accompanying the module is better than just a blog post, but that's just my opinion) and it is done for valid reasons there is absolutely no problem with that of course. Regarding the last 3.2.5 release, I haven't had time yet to fully test all my scripts but I have at least one that is failing now while it worked before. I will post a dedicated issue for that problem to avoid mixing things up. I don't remember which version exactly (probably the 3.0 or 3.1) but I remember having to change some classes namespaces after upgrading to a previous version. Not a huge deal of course and easy to spot and fix but this was not documented in your blog post.