Page tree
Skip to end of metadata
Go to start of metadata

Products go through varying procedures to get released.  It’s important to understand our terminology when communicating outward.  From a 50,000 foot view, the different stages look like:

Development -> Unstable (i.e., alfa - In stage folder) -> Release Candidate (i.e., beta - Still in stage folder) -> Release (accepted release copied to download repo) -> Unstable (Release + back-ported fixes - stage folder)   

Our process

  1. Product Management coordinates with support and developers and decides there are bugs, enhancements or new features (these are all broken down into ‘issues’) that need to be delivered to customers.
  2. Product Management determines the issues that will get assembled into a release based on severity, need and desired timeline for a release.
  3. Developers build code to solve the identified issue(s).
  4. Developers test their code and then merge their code into an Unstable build.
  5. Code undergoes testing in Unstable by QA.
  6. QA accepts the code as working or notes issues with it and sends it back to the developer.
  7. Once all of the issues slated for a release are completed the unstable build is smoke tested (quick install and basic functionality tests).
  8. With smoke tests completed, a Beta is declared and announced to customers and to the sipXcom community.
  9. Release Candidate (Beta) is installed on eZuce’s corporate system.
  10. A minimum time of 2 weeks will pass.
  11. Automated Testing team lead coordinates with manual testing team lead on test plan and initiates regression tests..
  12. If any regressions or bugs are found, Product Management is consulted and development is consulted for a fix or feature clarification.
  13. If further coding is required it is completed, tested, merged back into stage and the process starts again at step 11.
  14. Once all parties are satisfied with Release Candidate (Beta) the binaries are Released to customers on the download servers.
  15. Any additional patches back-ported to the release will be built in unstable repository because they are not fully regression tested with the rest of the code.

Explanation of Unstable

Before release this is a build that contains features that are still in development and slated for an upcoming release.  Features or bug fixes that make "large" changes are developed on separate code (git) branch called a "feature branch" away from all other code.  Once they pass a certain level of testing, then the branch is merged into the Stable branch.  This allows features to be integrated with the rest of the system code when they are determined to be in a stable state. 

Unstable build code is available to customers for testing from the following binary repositories:

Binaries :

Explanation of Release Candidate (beta)

Once a Release Candidate (beta) build is chosen, it goes through an outlined regression testing process.  If no regressions are found during the testing process, the exact set of binaries are copied to the appropriate release directory and user and customers are notified.  If bugs are found that are not regressions, release process can continue as normal depending on what the bug is.  This decision to continue with a known bug is up to Product Management.

Release Candidate code is available to customers for testing from the following binary repositories:

Binaries :

Explanation of Release

Release builds are accepted Release Candidates (Beta). These builds represent the most stable code produced by development to their knowledge. The Release build includes all bug fixes and any features that have passed the regression testing process and that no outstanding known bugs have been introduced.

Release build code is available to customers for testing from the following binary repositories:

Binaries :

Patches on top of Release

Any patches that are added to a release are only added to the stage (unstable) repository. We reuse that repository area so that we don't need to re-create a new one. It's important to note that this repository and the fixes applied are not fully regression tested.

Binaries :

  • No labels