You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide all the features we do provide now through the crossterm crate only. Archive sub-crates and inform all users.
This does not include crossterm_winapi, which can still be used by anyone outside the crossterm ecosystem.
We will end up with three active repositories:
crossterm-rs/crossterm
crossterm-rs/crossterm-winapi
crossterm-rs/examples
Motivation
There're dependencies between sub-crates we would like to avoid. Some of them are also using sys module, which needs to be public, but it shouldn't be. It's not part of the public API contract.
There're inconsistencies in examples, book, readmes, ... Some of the use crossterm crate with features, some of the use crossterm-* sub-crates, ... User can be puzzled what to use. In fact, it doesn't matter what the user will use, but the question is why we do provide two ways to achieve same thing.
And the last one is crossterm_utils, which is published as a crate, but it's not useful outside of them crossterm ecosystem.
Timeframe
There's no date set. I would like to focus on phase 1 now to finish the cleanup process I started. Once I finish it, I'll focus on bugs. Then, can be even distant future, discuss with Timon if it's the right time to merge.
Phase 1 - Cleanup
Improve & polish crates public (docs.rs & README) documentation (@zrzka):
Fix known bugs. The motivation here is to avoid archiving (GH) / deprecating (crates.io) buggy crates. Not all bugs can be fixed, especially those we don't know about, but rest should be fixed.
Goal
Provide all the features we do provide now through the
crossterm
crate only. Archive sub-crates and inform all users.This does not include
crossterm_winapi
, which can still be used by anyone outside thecrossterm
ecosystem.We will end up with three active repositories:
crossterm-rs/crossterm
crossterm-rs/crossterm-winapi
crossterm-rs/examples
Motivation
There're dependencies between sub-crates we would like to avoid. Some of them are also using
sys
module, which needs to be public, but it shouldn't be. It's not part of the public API contract.There're inconsistencies in examples, book, readmes, ... Some of the use
crossterm
crate with features, some of the usecrossterm-*
sub-crates, ... User can be puzzled what to use. In fact, it doesn't matter what the user will use, but the question is why we do provide two ways to achieve same thing.And the last one is
crossterm_utils
, which is published as a crate, but it's not useful outside of themcrossterm
ecosystem.Timeframe
There's no date set. I would like to focus on phase 1 now to finish the cleanup process I started. Once I finish it, I'll focus on bugs. Then, can be even distant future, discuss with Timon if it's the right time to merge.
Phase 1 - Cleanup
Improve & polish crates public (docs.rs & README) documentation (@zrzka):
cursor
- Internal refactoring and docs crossterm-cursor#2 & Sync docs style crossterm-cursor#7terminal
- Internal refactoring and documentation crossterm-terminal#3screen
- Refactoring and docs crossterm-screen#5style
- Refactors crossterm-style#2 & Sync documentation style crossterm-style#3input
- Refactor crossterm-input#3 & Improves the documentation crossterm-input#4utils
- Deprecation note crossterm-utils#3crossterm
- Docs update #269This includes copying the book chapters to their respective
lib.rs
modules.Phase 2 - Book removal
Then remove the book references from:
cursor
- Remove all references to the crossterm book crossterm-cursor#8terminal
- Remove all references to the crossterm book crossterm-terminal#4screen
- Remove all references to the crossterm book crossterm-screen#6style
- Remove all references to the crossterm book crossterm-style#4input
- Remove all references to the crossterm book crossterm-input#6utils
- Remove all references to the crossterm book crossterm-utils#4crossterm
(& the book itself) - Remove the crossterm book #270Phase 3 - Bug fixing
Fix known bugs. The motivation here is to avoid archiving (GH) / deprecating (crates.io) buggy crates. Not all bugs can be fixed, especially those we don't know about, but rest should be fixed.
List of issues/tasks
Windows related
All platforms
ResetColor
ResetColor
command #274UNIX
read_sync
fails under LLDB debugging in Linux #253Reminder
Just a check to go through the issues again if there isn't any new critical issue.
Phase 4 - Release
For every sub-crate:
lib.rs
that the crate is deprecated and no longer maintained.Cargo.toml
and add[badges] maintenance = { status = "deprecated" }
crossterm
cratecrossterm
crate with updated dependenciesBy the end of this phase, all sub-crates are polished, hopefully, bug-free and marked as deprecated.
Phase 5 - Merge
For every sub-crate
Stop accepting sub-crates PRs (already archived) and copy the code to the
crossterm
crate. This step requires (for every sub-crate):crossterm
module (crossterm_cursor
->cursor
)use crossterm_cursor
->crossterm
)crate
will differ, etc.)input
requiresscreen
, theinput
feature must enablescreen
feature as well)utils
screen
style
input
cursor
terminal
crossterm
crateOnce everything is merged, documentation is updated, etc.
crossterm
crate versionPhase 6 - Inform users
Not need to inform the following projects
All of them are using
crossterm
crate directly.The text was updated successfully, but these errors were encountered: