A common model in the open source community (who are more accustomed to rapid release cycles than others) would be to maintain the last semi-major version tree as the "stable", getting only bug fixes, while the current "bleeding edge" gets features. So for the current state of Eagle, you would provide both of:
v8.4.x is the stable, bug fixes only path
v8.5.y has all the latest features
Then at some point you would decide that 8.5 is now feature-stable, create 8.6.0 for new feature stuff and obsolete 8.4 because 8.5 has become stable.
As a minor variation of that, the Linux kernel used to run a scheme where the middle number was even if stable and odd if development. Hence v2.24.x was a stable version, v2.25.y was development, and when that series got stabilised it became v2.26.0 making v2.27.x the new development branch.
This approach allows your users to choose (gosh, what radical concept) whether they want to play with the latest features or get on with work on a stable platform.