Testing with old versions makes little sense. Only do it to familiarize QA team with new features (if changes are not radical), and develop testing protocols and tools.
To deal with changes in system to be released, we use "soft freeze" and "hard freeze".
During "soft freeze" changes in released software need to be approved by QA (and are evaluated for likelihood of breaking system under test), and/or chances to adding new unknown bugs. It depends on developer, affected subsystem, and complexity of the change.
During 'hard freeze" we run all tests again, and no changes in released software are allowed. Most patches requested during "hard freeze" are delayed for after the release. Or if decision is made that urgent patch has to be made before release to "hard frozen" system, there is understanding that defects might sneak in, which QA was not able to detect, because system under test was changed.
Idea is that QA cannot "assure" that release has no (unknown) bugs, but provide best information to management about the risk of releasing software with bugs.
Decision to release on a given date (or postponing the release to allow for more testing, if necessary) is management decision, and role of QA is to approximate the risk. Fixing the bugs is responsibility of developers, and evaluation the risk/value is management decision.
We all work as a team (developers, QA, management) to deliver the best (most features) and most reliable system in the time and personnel available. If you do not have such level of trust, and after botched release there is fingerpointing, shifting the blame, and searching for sacrificial goat to blame, everyone will start padding the estimates and speed of the development will decrease. Let management to manage the project, but QA should provide best info about the status of the project it can.
Regarding versions of the third party software, you need to decide which versions you support (with the limited resources you have), which versions you do not, and which versions will get obsoleted in some defined timeframe. Do you have control over which version your user use? If not, some users will have to deal with bugs limited to their version - and again, your management has to decide what threshold of such bugs is acceptable. So you may not support most recent "bleeding edge" version (if you decide so), only 2-3 previous "stable" versions. Then you need to detect which version user uses, and issue proper message.
Again, your role is to investigate the risk involved with different versions, and provide info to management to make business decisions and allocate resources as makes business sense.