Maintain backwards compatibility and/or upgrade log



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,


Camelot wrote Apr 29, 2016 at 7:01 PM

At first, I appreciate that you find this project helpful for your environment.

I understand your concerns about compatibility and this is where I try to pay a lot of attention. I would say that compatibility is my top priority because of what you said.

However, different parts of code were written long ago when I haven't had a good design view on particular API set, as the resut the code was bad from design and maintenance perspective. And to provide better functionality some parts must be changed regardless of compatibility requirements. For each release I post a blog post under PowerShell PKI module category on my weblog where I provide information about changes in each new version.

In any way, if you have a particular issue, you can ask it in the Discussions tab and I will try to resolve it.

jalliot wrote May 3, 2016 at 2:15 PM

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.

jalliot wrote May 3, 2016 at 2:25 PM

Oh I posted too fast. There is a new BC break regarding classes namespaces in this release.
We could of course have expected it since you split your 2 .NET libraries but any code using [PKI.ASN.ASN1] that worked before no longer does.

Camelot wrote May 5, 2016 at 5:04 PM

I got your point. I'll try to do all my best here. Though, I have to make additional learning about the subject.

Camelot wrote Aug 9, 2016 at 6:25 PM

FYI, since all sources are now on GitHub you can track all changes in changelogs.