Right, it would work the same with Linux. Making a panda3d.rpm and a panda3d-devel.rpm would be a sensible division, consistent with other software.
I don’t mean to strip the minor number from the release altogether. It should still be part of the download and so on. But it shouldn’t be part of the installed filename, so that downloading 1.6.3 will replace 1.6.2, for instance, but have no effect on 1.5.4. Also, it (probably) shouldn’t be part of the version-requirement system, whatever that will be. If a particular package says it requires version 1.6, it should be allowed to run with 1.6.2, or 1.6.3, or whatever minor version of 1.6 the user happens to have around.
I’d say, whenever it’s ready. No reason to rush it out too soon.
I wonder about that, too.
Right, well, really it’s just a problem with distributing additional compiled C++ code in general. We could allow this, by allowing pyd’s (or dll’s) in the mf file and unpacking them and loading them, though this impedes portability.
The add-on proposal is a workable solution that might help the portability issue, provided the add-on developer is willing and able to compile his add-on for every available platform. (Of course, if the developer could do this, he could also bundle up all of the dll’s, so’s, and dylib’s in his mf file.)
It all sounds terribly complicated, though, and my first suggestion is to keep thinking about solutions for this problem in the back of our minds, but not to let the existence of the problem prevent us from doing the easy thing for pure Python applications.
David