Repository navigation
Version 1 road map, or whatever you decide to call “stable”… #1992
Description
This is not really a bug, more a request for clarity.
First, I really like ruff and I do want to make it my go-to tool for linting. Currently, using it takes some effort to update as the release versions are coming fast and frequently. This is, of course, fine and understandable as it is under massive development. Kudos to everyone working on it, your efforts are much appreciated.
What I am looking for is a vague and non-binding roadmap to a “stable” version (let's call it v1!) so that I can plan a massive upgrade.
Reacted by Maksym Kryvchun, Charlie Marsh, Adam Rafajdus, Dillon Fearns, Clément Robert, Nyakku Shigure, John Hagen, Steven Silvester, Hugo van Kemenade, Hash and 12 more
Metadata
Metadata
Assignees
Labels
No labels
Activity
charliermarsh commentedon Jan 19, 2023
Totally hear you and thanks for the kind words. I have a bunch of thoughts here of course 😂 I'll try to write something up later today if I can!
Dilski commentedon Jan 24, 2023
I would like to adopt Ruff as our main tool for linting, but our main blocker is the v1/stable release. For now however, we're going to be running ruff alongside our other linting tools (flake8, bandit, etc).
charliermarsh commentedon Jan 24, 2023
I got delayed on this, but I'll post some thoughts on what I want to see in a "stable" release by the end of the week!
charliermarsh commentedon Jan 26, 2023
Here's what I'd like to see going into a Version 1 (which I assume would be
v0.1.0, but let's punt that discussion for now):explanationmethod on Rule struct via rustdoc #2642)As you can see, there are a few potentially-breaking changes in there. The intent is for them to be fully backwards-compatible, but I can't process complete backwards compatibility yet.
To put this in higher-level terms, I want Ruff to hit two milestones before bumping to
v0.1.0:E501and friends), and is missing some key concepts (like "safety levels" for autofixes). We want to implement those missing concepts, and put some new abstractions in place (e.g., users should be able to do things like enable all "correctness" or "style" rules without having to parse through the list of implemented Flake8 plugins) while maintaining compatibility with the Flake8-oriented system. (Compatibility is an important piece here. We now have a lot of users -- which is great! -- but it comes with responsibility.)I don't know when exactly we'll be able to bump to
v0.1.0. I mean, definitely this year, but not this month.Here are a few things that aren't important to me, with respect to bumping to
v0.1.0:v0.1.0:)) before we consider doing this.rufffrom Python, or from Rust). Same as above.This is all based on current thinking and I reserve the right to deviate from this path as time goes on 😅 But hopefully this is helpful. Feedback always welcome.
charliermarsh commentedon Jan 26, 2023
I'll \cc @not-my-profile on this issue too, actually, as he's doing a lot of work related to those rule and diagnostic API improvements.
not-my-profile commentedon Jan 26, 2023
I'd add More thorough documentation for rules (#1467).
hugovk commentedon Jan 27, 2023
And using SemVer:
There's a couple of dozen big projects listed on https://github.com/charliermarsh/ruff already using Ruff in production :)
All planned for "Version 1": #1992 (comment) :)
Sawbez commentedon Feb 11, 2023
@charliermarsh You might consider pinning this, putting this in a milestone, or putting this general information in a
ROADMAP.mdand link it in theREADME. We could also use the roadmap for version 2 and 3 (presumably 2 is formatting, 3 is type checking if we go that far) and possibly other big changes that contributors or users might want to help with/look forward to.That might be too much maintainer time on top of all the things you have to manage, so not doing any of these would also be 100% okay.
sbrugman commentedon Feb 16, 2023
The closest issue that we have open related to this is #1997 (I think)
charliermarsh commentedon Feb 21, 2023
We're making good progress on this!
Now that we support all Python 3.10 and Python 3.11 syntax, we can start seriously considering a "stable" release (that is, if we wanted to punt some of the features listed above to "post-0.1").
I think "Editions" would be a good thing to do since it gives us a mechanism to change configuration in the future in a backwards-compatible way.
pauloxnet commentedon Apr 6, 2023
I'm waiting for the first stable release to propose ruff adoption to big python project (e.g. Django).😅
Thanks for all the work you all are doing. 👍
tgross35 commentedon Jun 14, 2023
Is there any specific place you're tracking the editions concept? Quick notes:
edition = "2023") or quarterly (edition = 2023-Q3) editions seems like a reasonable duration (as compared to Rust's every 3 years)ruffversions pinned for relatively long timeszanieb commentedon Aug 30, 2023
Hi! We're looking at publishing a versioning policy for
v0.1.x. Check out the proposal at #6998, we'd love your feedback.@tgross35 We have not invested more effort into editions yet. It may need to be a
v1.0.0+feature.charliermarsh commentedon Jan 10, 2024
We shipped v0.1.0 a while back, which included a clear versioning policy -- and we're now looking ahead to a bunch of stabilizations in v0.2.0 in the near future -- so I'm going to close this out for now.
We still have some big changes planned for the future that will likely change the API (e.g., we want to do a holistic recategorization of the rules at some point; we may add support for custom rules; we'd like to ship a programmatic API, to call Ruff from Python). But all of those changes will follow the versioning policy defined above, and will be shipped with appropriate deprecations and compatibility guarantees over time.