... for any value of "X"
Like most software projects, sipXecs has approximate target dates for when any given release will happen. Like most software projects, those target dates are not always metVersion 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 issues that have commercial importance may not show, and some problems known to QA and/or the developers may not have been filed yet, so the picture is not always perfect). There is some lag from the last issues being Resolved to a release as the builds are subjected to final QA; sometimes, releases are posted in the public download areas during this period, but if you don't see an announcement on the list and the LatestStable link is not switched to it yet, then you should not consider it released yet.
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 with sipXecsor request a feature.
Will
...
next release fix XX-????
Two important things to note in an issue:
...
- 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.