what do panda version numbers mean?

is there a specific formula that determines how the panda release number will be incremented? is api or abi consistency not guaranteed between given releases?

i’ve built a tiny helper for my panda scripts, which is compiled and linked against panda. specifically, it uses the Texture class. do i need to (and, separately, should i as a responsible programmer) compile my module fresh for every patch-level release of panda? for every minor-level?


In general, the release numbers are 1.major.minor, where the major version changes with new feature sets, and the minor version changes with bugfixes.

Since this is C++, we can’t really guarantee that the ABI remains unchanged with minor version changes, although it is likely to. It’s always best to recompile any C++ code with each new release.


The version numbers are always like A.B.C, where A has never been other than 1, the B means the major release and C is minor release.
Usually, the X.X.0 releases contain the major features and stuff. Therefore, those are usually the least stable.
The X.X.1 releases do still implement only small features (but most of em bugfixes), and the X.X.2 will only contain bugfixes (although there can slip a tiny feature in there, there is considerable flexibility in the rule).
1.5.3 has been an exception, for various reasons.

The Panda3D versions are not binary-compatible with each other at all.

I vote for making all minor releases in a branch binary-compatible with each other (making the panda version symbol e.g. panda_version_1_6 instead of panda_version_1_6_0). That would pave the way for future runtime-only builds too.

EDIT: oh look, I was too late! drwr was faster :slight_smile:

thanks for the reply. i was hoping for better news, but that’s not a huge problem. so riddle me this:

what are the supported methods for retreiving the panda version information from the os|shell, i.e. without writing any panda code?

This would be great, but I’m not sure it’s possible. Python can do it fairly easily because Python is written entirely in C, which gives the programmer a lot more explicit control over the ABI. In C++, little things like changing a default parameter or reordering virtual methods can dramatically affect the ABI and render the code binary incompatible. It would be possible to restrict ourselves to changes that preserve binary compatibility, but I worry that this may overmuch limit the nature of bugfixes we can commit.

I imagine you’re limited to examining the directory names. We have thus far not made an effort towards determining which Panda version(s) are already installed in a system, sorry about that.