Version 4.6 and associated Update XX was the last of the "it will release when it's ready" releases.

Starting in April of 2014 we have moved to a regular feature release cycle of April and October.

The first such release is numbered 14.04, the next release in October of 2014 will be 14.10. The subsequent release will be 15.04.

There may be bug fixes between feature releases and these will not be at planned intervals but instead as needed. The first bug fix release for 14.04 will be 14.04.1, the second 14.04.2, etc.

We start feature release planning before a current release is actually completed. Just because an issue is planned to be worked on in a particular version doesn't mean that it will be completed within that version. If the feature or issue is not completed or satisfactory by the time code complete arrives (approximately 2 months before release) that issue will (at the discretion of Product Management) slip to the next release.

The best way to watch the progress toward any given release is the sipXecs Project Roadmap page in the issue tracker. If you see lots of Unresolved issues, the release is probably not happening soon. If you don't see any Unresolved issues, it probably is soon (note however, that some problems known to QA and/or the developers may not have been filed yet, so the picture is not always perfect).

The issue tracker is how we track everything we're doing... to see the flow for how an issue is created and progresses, see How to report a problem or request a feature.

Will next release fix XX-????

Two important things to note in an issue:

Fix Version
in an Unresolved issue, this is the release (or sometimes releases) that we plan to address the issue.
in a Resolved issue means that the issue has been addressed, and that's the release it will be available in.
if Fix Version is empty, the issue is not scheduled for any release yet (which could be an oversight - feel free to ask on the mailing list)

Plans sometimes change, but you can use the Priority to get some idea of this:

Blocker or Critical
issues are ones that we currently believe the release cannot do without. Any lower priority issues might be moved to a later release in order to avoid holding up features or fixes that the community needs more urgently.

For getting a feature or issue into a given release, the process is as follows (features are broken down into one or more issues):

Product Management (PM) decides that a Feature or Issue should to be addressed in version XX.XX.x and moves the issue to the IceBox queue.
More important Features / Issues are moved to Backlog (i.e., closer to being worked on).
Development iterations are planned every 2 weeks. At the beginning of each iteration issues planned for the iteration are moved to Awaiting Development (or carried forward from a previous iteration if not completed).
As issues are resolved they are passed to QA to verify new functionality or verify that a bug is addressed. If it is, it is moved into a stage branch, if it is not it is returned to the developer to address shortcomings.
If all of the issues that make up a feature are completed in time for code complete (if PM decides a feature is critical for release, a feature may creep into QA period or may 'phase in' a feature) the code will be included release candidate for full QA and regression testing.
Assuming that an issue passes QA and regression testing it will be included in a release. If it does not pass it may be included in a subsequent release (or re-designed and re-sent through process all over again).

You should also understand Version Numbers.