Versioning of ActiveX COM DLL with Semantic Versioning but GUID per MAJOR.MINOR? -


long story short, i'm maintainer of visualbasic 6 project products activex com dll used internally ~50 other software packages have internal uses in organization.

for last couple years have been following semantic versioning "major.minor.patch" each dll released , have been assigning unique guid per release. i.e. 1.1.1 , 1.1.2 have separate guids.

it has worked ok, causes each of software packages require new release -- when none needed -- can reference new guid , recompile. wastes few dozen man hours due internal processes releases.

my question is, "bad practice" maintain guid each minor release 1.1.1, 1.1.2, , 1.1.99 have same guid? better guid per major release instead?

this cause references change when new major or minor release made reducing number of changes required software packages depend on it.

lastly, if helps response, dlls named as: myactivexdll_vmajor.minor.patch.dll.

with guid per minor switch myactivexdll_vmajor.minor.dll

it possible not changing guid (you can set in class builder, , stored in hidden attributes can see if open source file in notepad), can if aren't making breaking changes.

breaking changes are:

  • interface changes (added/changed/removed/re-ordered methods/properties)
    • includes changes dispids, parameter orders, parameter names
  • removed interfaces
  • methods worked before don't now. (only problem if method used. if no longer used, can deprecate , have throw error, not rid of it).

in vb default relying on auto-generated dispids, guids , interfaces. can set these particular values using class builder.

you can set initial values auto-generated values in previous release. have hand - have open type library in tlbview find out are.


Comments

Popular posts from this blog

php - Submit Form Data without Reloading page -

linux - Rails running on virtual machine in Windows -

php - $params->set Array between square bracket -