Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add blogpost planning towards 1.0 and slowing releases #957

Merged
merged 9 commits into from
Jun 27, 2023
Prev Previous commit
Next Next commit
Spelling fixes based on Darren's comments
  • Loading branch information
sholderbach committed Jun 27, 2023
commit e3e5747693f1cbb88b0df6f78eb69adfdf945eae
6 changes: 3 additions & 3 deletions blog/2023-06-26-road-to-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Reaching a nu phase in Nushell's development - The road from 0.82 to 1.0
author: The Nu Authors
author_site: https://twitter.com/nu_shell
author_image: https://www.nushell.sh/blog/images/nu_logo.png
excerpt: Ahead of the 0.82 release we share our plans on how we intend to stabilize for 1.0 and announce that we slow to a four-week release schedule.
excerpt: Ahead of the 0.82 release, we share our plans on how we intend to stabilize for 1.0 and announce that we slow to a four-week release schedule.
---


Expand Down Expand Up @@ -71,9 +71,9 @@ Achieving stability will not be possible without all of you that have dedicated
We want to incorporate you in formulating the priorities for the 1.0 release by reaching out to folks interested in particular problems to get clearer roadmaps for specific areas. Those write-ups will hopefully also provide some inspiration for folks interested in helping out and pushing Nushell forward.

But setting our sights on reaching the stable 1.0 release will also impose some limitations on our development practices. We are now much less likely to accept new features, commands, or options as they need to work well together with the larger picture.
A lot of effort will still need to go into cleaning up the internals and fixing bugs. As we want to systematically improve our binary size, compile times, and runtime performance, improving existing algorithms and paying back technial debt will be prioritized over experimental stuff.
A lot of effort will still need to go into cleaning up the internals and fixing bugs. As we want to systematically improve our binary size, compile times, and runtime performance, improving existing algorithms and paying back technical debt will be prioritized over experimental stuff.
Any external dependencies will also come under much more scrutiny.
This means, to reduce the total number of we will seek to replace redundant or mostly superfluous dependencies with fewer high-quality implementations and also severely restrict the addition of any new dependencies.
This means, to reduce the total number of crates we will seek to replace redundant or mostly superfluous dependencies with fewer high-quality implementations and also severely restrict the addition of any new dependencies.

## How you can help out

Expand Down