xSocket's understanding of alpha, beta and final


alpha A component in alpha mode is a full functional, working, not performance-optimized component. Not performance-optimized doesn't mean that the component is slow. It just says that dedicated performance optimization work tasks haven’t been performed.

The component's API/SPI is subject of change. Alpha doesn’t mean experimental! Experimental components can be found in the sandbox branch of xSocket’s code repository.

Alpha requires more test/example/early applications to see that the component works conveniently for different use case. To ensure high quality, the API/SPI has to show high flexibility and usability in the (pre) practice. Test/example/early applications of the community, support and feedback are very welcome and important. As more community feedback and support as shorter the pre final phases.

beta

A component in beta mode is a full functional, working, not performance-optimized component. The API/SPI is (almost) stable. Changes of the API/SPI should be avoided and have to be minor changes. During the beta phase the implementation will be optimized without modifying the functionality.

Normally a beta phase is up to 1-2 month.

final A final compoment is a full functional, working, performance-optimized component. The API/SPI is stable. Incompatible changes of the API/SPI lead to a new major version. The old major version will be in a maintenance support mode. Compatible changes can cause deprecating classes and methods.

Preconditions of a (alpha/beta/final) release:

  • all provided methods and classes are fully implemented
  • no bugs of the version to release are known
  • sufficient automated tests exists (xSocket’s current TestCode-to-ProductiveCode ratio is ~ 1:1)
  • all test have to be passed (this is also a precondition for a repository check-in)
  • sufficient documentation exists