List view
- Overdue by 10 month(s)•Due by July 12, 2024•8/8 issues closed
# 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.
Overdue by 9 month(s)•Due by August 30, 2024•74/100 issues closed# Terminal.Gui v2 Alpha Release Criterion These are the criteria we will use to decide whether V2 Alpha can be released. Unitl the Alpha is released, 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 Alpha Goals - **Make v2_develop the primary Terminal.Gui** branch - **Publish `v2.0.0.0-alpha` package on nuget** - **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. ## Alpha Exit Criteria - No known pri 0 or pri 1 bugs in the V2 Alpha Milestone.
Overdue by 9 month(s)•Due by August 16, 2024•101/127 issues closed# Themes for v2 * **Improve performance and compatibility on non-Windows systems**. The current `ConsoleDriver` architecture and implementation, especially w.r.t. Linux/curses has deep flaws and poor performance relative to `WindowsDriver` on Windows. * **Address the biggest bug farms**. For example, we have almost no unit test coverage for `ConsoleDriver`s yet we continually get regressions and complex bugs in them. * **Update Visual Style**. The current visual style is a bit awkward, deriving from the constrained simplicity of Midnight Commander. Other TUI frameworks of old, did some things right and we should take the best of them and update Terminal.Gui's visual style (Norton Command, TurboPascal). For example, see #2144. * **Colors**. We must add true color support, support for more flexible theming, and end-user color choices. Also, support things like blink/underline and some sort of markup (e.g. attributed label/ANSI/etc...). * **Improve text editing and formatting**. We learned a ton in the past few years by improving `TextView`, `TextFormatter`, etc... But we made some errors and things like word wrapping are still not as good as they need to be for a text-based library. * **Address weird/legacy API issues**. Early `gui.cs` design decisions, combined with subsequent upgrades have led to areas of the API that just don't make sense to new devs. One example is how weird `Window`'s `Border` and `Padding` work (and why `FrameView` exists at all). Another is the clunkiness of using `ScrollView`. * **Leverage Modern .NET Tech**. Examples: Nullable Reference Types, using `System.Rune` vs. `Nstack`, and MAUI. # V2 [Tenets](https://ceklog.kindel.com/2020/02/10/tenets/) for v2 (Unless you know better ones) * **Don't Overdo It**. v2 will be a major overhaul and we can take breaking changes, but we try to not cause v1 developers too much pain in migrating. * **Always Better Performance**. We ensure v2 is measurably faster, has lower latency, and feels snappier than v1. We don't make changes that regress performance. * **Simplify Getting Started**. We invest in v2 capabilities that make it easier for devs to get started and are biased against things that make onboarding more difficult. # V2 Release Criterion These are the criteria we will use to decide whether V2 can be Released. After Beta, we will not accept any PR into v2_develop that does not meet these criteria. ## V2 Release Goals - TBD ## 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 Release Project @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.
Overdue by 9 month(s)•Due by September 6, 2024•65/113 issues closed