Skip to content

V2 Beta

Past due by 4 months 60% complete

V2 Beta Release Criterion

These are the criteria we will use to decide whether V2 Beta can be released. Once we agree on these criteria, we will use them to classify all existing and future Issues.

We will not accept any PR into v2_develop that does not meet these criteria.

By taking this approach we can get all contributors focused on a release and get i…

V2 Beta Release Criterion

These are the criteria we will use to decide whether V2 Beta can be released. Once we agree on these criteria, we will use them to classify all existing and future Issues.

We will not accept any PR into v2_develop that does not meet these criteria.

By taking this approach we can get all contributors focused on a release and get it out as quickly as possible.

V2 Beta Goals

  • API Feature Complete. V1 functionality not replaced by V2 functionality still works as well as it did in v1. New functionality works as described in the API docs. We have no known issues that will require breaking API changes.
  • Visual Structure Locked. Key UI (look and feel) elements are in place and devs can expect apps built with the beta to look fundamentally the same when v2 releases. This includes default colors, default line styles, Border/Title layout, menu/dialog/etc layout.
  • Stable API. Enable developers to retarget legacy/v1 apps with the confidence of a stable API. IOW, after v2 Beta we will have a high bar for breaking API changes.
  • No egregious performance issues.
  • Cross Platform. Mainline scenarios work consistently and well on Windows, Mac, and Linux.
  • CI/CD is setup for long-term support. This means the v2_develop is the default branch, the v2 API docs are primary, and v1 can be supported in parallel. It also means we have a branching strategy that supports parallel development of post-Beta, and post-v2 features while we're supporting the Beta.

Priority definitions for Issues

  • 0 - Development is Blocked. Nothing is more important than fixing immediately. All pri 0 Issues must have an owner set. If the owner can't work on the Issue immediately, he/she will assign it to someone who can.

  • 1 - Release Blocker - Issue needs to be resolved in order to ship the Release. We will not release until this issue is addressed. All pri 1 Issues must have an owner set. That individual is responsible for doing whatever it takes to get the Issue resolved as quickly as possible. If the owner can't work on the issue, they are responsible for finding someone else to take ownership.

  • 2 - Nice to Have. We want this issue fixed in the Release, but we will ship without it and address it later if we can't get it done in time. Ideally, pri2 issues have an owner set, but don't have to.

  • 3 - Not in Release. The Issue will not be addressed in this release but may be in a later one.

Beta Exit Criteria

  • No known pri 0 or pri 1 bugs in the V2 Beta Milestone.
  • @tznind declares TG.Designer is ready for v2 Beta.
  • OCGV is v2 based
    and the Powershell team agrees it can replace the v1 version once TG v2 releases.
  • At least 2 other externally developed TG apps have been ported and their devs agree there are no beta blockers.
  • We have a visually killer demo/showcase GIF of the new v2 look and feel.
  • All Conceptual Docs and READMEs are updated and accurate for v2.

If we focus as a team on meeting these criteria, we can get the Beta out the door quickly and continue to innovate on top of it for years to come!

@tig will be the Release Owner. He will take responsibly for driving the team to release. He will do the structural work required to keep us organized and focused. He has final say on Issue priority and the final call on release readiness.

Loading