1.0 timeline?

[kamalmarhubi]

I saw @nrc's post on the users forum, where he says

Over the next few months, we're making a big push to release a v1.0 for Rustfmt.

What's the timeline for this? I have a few issues I'd really like to get into a 1.0, so I'd like to get an idea of how to prioritise vs other projects.

Really excited for a 1.0!

[nrc]

Tentatively, I'd like to be done by the end of June. You can see the list of issues I think we need to solve by 1.0 here. It is kind of a long list, so that deadline might be optimistic.

I also want to get rustfmt running on the whole Rust repo in that timeframe, and that is a slightly higher priority for me than the actual 1.0 release (although the two are certainly related - I consider running on the repo the benchmark for when 1.0 is 'ready').

What issues do you have in mind?

[kamalmarhubi]

My big one is #434, and the associated cargo fmt-diff or rustfmt --diff command I haven't written about anywhere. I think it's really important to be able to introduce something like rustfmt slowly, one commit at a time. Otherwise you end up with unfortunate situations like this: rust-num/num#164 (comment).

I'm getting close on a first cut of rustfmt --file-lines (or whatever the flag is), but there will be a fair bit of tweaking to do.

Other than that, there's some config related items: #871, #872, #873. And some warts like #803. I'd really like to redesign the CLI a bit which should happen before a 1.0 since editor integrations / CI / pre-commit hooks will be calling it.

[kamalmarhubi]

In general, I strongly care about user experience over details of formatting. I'll take a look at those issues and see if there are any that fall under that umbrella.

[kamalmarhubi]

On that note, I just remembered that error handling and reporting is another area that could do with some attention. Haven't perused issues enough to know if there are already bugs filed, but there are a fair number of improvements to be made!

[nrc]

Cool, they're all things I'd really like to see soon. I think only #873 is really a blocker for 1.0, plus any CLI redesign (we should have something like #905 for command line options). #434 would be really great to have.

My focus for 1.0 is stability - I'd like to have backwards compatability guarantees for the overall mode of operation and a core of command line and config options. Second is reliability - I want us to run on as much code as possible without crashing or breaking the code. I'm happy for the actual quality of formatting to improve after the 1.0 release.

[kamalmarhubi]

Tentative timeline: end of June. List of 1.0 milestone issues.

[kamalmarhubi]

Closing since question was answered.