Please define "Side-by-side approaches".
So far i haven't heard any specifics of a solution other than a dozen dlls and cfg files, one per version.
For it to be easy for the user, there should be one modules/genericvessel.dll and one config/spacecraft/genericvessel.cfg, neither of which is afraid of being overwritten.
Versioning...
A version tag in the ini file.
modules/genericvessel.dll is a dumb wrapper, that looks for this tag, interprets it, and passes on to another dll.
If there is no tag - load SC3 version/latest version.
The actual dlls are version-named, and stored in a separate directory (for convenience). Developers distribute add-ons with whatever version dll they want, as well as never-changing wrappers.
Should work.
This is exactly what I had in mind with side-by-side. That's why I'm not boring you with complicated explanations: you always understand the technical terms, anyway.
Also, makes a perfect dll hell, Microsoft-style.
And here we disagree. It is actually the approach Microsoft took to deal with DLL hell, and IMHO it works well, whereas the cathedral approach did not work for them, although they where in the perfect position to enforce it.
Anyway, I'm going to implement this feature in my version. Since the two approaches don't really exclude each other, genericvessel users can always choose if they want to include the runtime in their addon distribution for a turn-key end-user experience, or instead want the end-user to deal with it on his own. No loss either way.
If GV used a distribution system
like Orbiter Beta (TortoiseSVN for example) everyone would always have the latest version. This would be great!
Actually that would be the cathedral approach I was talking about, as in "go to the cathedral and pray for an update". This works for Orbiter because nobody is working on it besides Martin alone. This works also for e.g. DanSteph, because he does not open up the source to OS/UMmu/UCGO, and so naturally can dictate what and when something goes out and is considered "latest".
That's all fine and dandy, until a bus hits one of the cathedral masters (which hopefully never, ever happens in the case of Martin, DanSteph or Artlav!). Or until one of them decides that his time is better spent on other things in life.
Then you are suddenly again locked-in to a system nobody can extend/update anymore.
Now fortunately things don't look that bleak in this case, mind you! Having genericvessel GPL'ed almost guarantees that people at least don't have to rewrite everything from scratch again. Still the distribution decisions we take now will influence the situation/eco-system at that imaginable point in the future where again maintainers have to be switched.
He obviously knows versioning systems in and out, and this deep knowledge "makes" him naturally use a high-level technical language, sometimes a bit too high for me...
I'm sorry for the technical language, but I deal with similar issues at work every freakin' day, so naturally I speak up if decisions are made - especially on forks of a project I started - that IMHO take the wrong turn. Most of that language was addressed to Artlav, because I assume that he understands it, based on the level of insight he presented in the past. And as you can see from his answer, the assumption was not too far away from the reality.