So, in the .next alpha image thread, ajs124 said:
And I said:Hm, I wonder what that library does? I only maintain one application in the repo (SpaceFM, it fails to start because of libudev), but what is the "policy" for application maintainers? What if fixing a pnd for .next breaks it for SuperZaxxon?
And Askarus was all like:My plan for my PNDs that need updating for .next was for there to a temporary period where the PND contains enough stuff for both SuperZaxxon and .next, and the startup script chooses between them.
So, internally, it would have:
and the startup script would do:
if [ OS == .next ]
That said, once .next is officially released, we don't have to support superzaxxon any more - anybody still using it for whatever reason can always download an archived copy of a PND.
But then hmc came back with
Anyways, so I thought I should create a new thread for it, 'cos it's the kind of thing we can have a big fun argument about.I only partially agree.
There may be reasons for people to stay on SuperZaxxon for some time, even after .next is released.
Or will you only release .next, once EVERYTHING works flawlessly in it, that already worked flawlessly on SuperZaxxon? Then it may be okay to drop SuperZaxxon support in newer PNDs.
However, no matter how the answer to above question is, during the time when both firmware variants are around, these problems will occur:
1. It will create big efforts for PND maintainers to support both firmware variants in the way you describe, freamon
2. Many PNDs won't be upgraded during that time, or even not at all anymore, so they will never be comatible with .next, even if they could if only one lib was removed / replaced.
So I suggest rather finding another solution to make old PNDs also run in .next, e.g. by providing some "compatibility mode" (reminds you of Windows? Yes, sort of ;-).
I am not enough of an expert to guess, if something like that could work with reasonable efforts, but what about solving most PND lib problems with symlinks, and those that are not solvable with symlinks, solve with providing SZ lib version AND .next lib version in parallel in some way? If not both lib versions can coexist in one system, then some switching mechanism, that symlinks either version in place could be used maybe?