Skip to end of metadata
Go to start of metadata

Updated  

The content and scheduling of a TAPI release is described at TAPI Roadmap 2023 page.

Any major TAPI release (vX.Y) must be associated to a TAPI RIA version (vA.B)

The development of TAPI RIA Requirements and Use Cases guides the development of TAPI model (from Requirements and Use Cases to Model).

When a meaningful/identified/consistent set of features have been consolidated in RIA discussions, an intermediate TAPI releases (v.X.Y.Z) can be delivered.

Process to be followed for the delivery of a TAPI Major Release

A pre-release major version is declared to be "ready for review" at a regular TAPI call.

It is required that at least half of the OTCC TST members (see Open Transport Configuration and Control Home) provide a vote on the available voting page (e.g. TAPI Release v2.3.1 Approval).

The vote is extended to all contributors, where a contributor is attending TAPI calls regularly.

The vote may be extended to all downstream consumers of TAPI.

The possible votes are yes, no and abstain.

  • For approval, a certain percentage of yes votes is defined:
    • besides being more than no's, the approval requires that at least 1/3 of votes are yes.
  • The review period shall not exceed two full working weeks.
  • As a general rule, no further modifications are allowed during the review period.
    • During TAPI regular calls small fixes can be agreed and tracked in the voting page.
  • Deadline date for voting shall be specified in the TAPI call minutes and in the dedicated voting page.
  • Comments can be added to the dedicated column in the voting page.
    • A negative vote must be motivated by specific comment(s), otherwise will be considered as a "void vote".
  • The review period can end in only two ways:
    • Delivery is agreed: there are enough yes votes according to the rules.
    • Delivery is not agreed: all other cases.
      • The delivery release process must be repeated.
        • Explore "fast process" option.
        • Explore "deadlock avoidance" process, e.g. after two failed reviews reduce quorum, and/or dedicated vote to solve a conflict.