Burst additional command in two files #6641
Conversation
|
See #6589 (comment). I am -0.5 on this change. I think the |
Pull Request Test Coverage Report for Build 2350387317
💛 - Coveralls |
Pierre-Sassoulas
force-pushed
the
move-additional-command-to-user-guide
branch
from
55dbbf6 to
9025815
Compare
Pierre-Sassoulas
changed the title
Pierre-Sassoulas
force-pushed
the
move-additional-command-to-user-guide
branch
from
9025815 to
2d3853f
Compare
You're right, I updated the MR accordingly.
What do you have in mind ? |
|
What about |
|
Edit: answered too fast, I'm ok with merging pyreverse/symilar in a usage and configuration section. |
I would do: Tutorial
Usage and configuration
Development
Additional included programs
Changelogs
ContactAlthough I'm not 100% on |
|
Regarding Changelogs my idea is to separate changelog for dev and changelog for users so in order to do that it would make sense to have two changelogs, one in |
Can't we do two sections in the same changelog? Why would we force developers to look in two places? We could just make an |
The plugin developers are maybe 0.5% of total users, and they're power users very knowledgable in pylint. We could separate the two changelog so the vast majority of user do not have to triage what they should read in the changelog. |
Yeah, but still. I often look back at older changelogs to see when something changed and I tend to look at the changelogs of other projects as well. That can often give you inspiration about relevant changes. If the internal changes are separated from the user-facing changes in a separate section I really don't think any user will mind. |
|
That would work . But we also have old changelogs to display. Unless we want to triage the old changelog it would be convenient to keep whatsnew (user facing changelog) and changelog (dev facing changelog) separated. |
|
Just from the I'm nog suggesting to move those around, but just to illustrate that we already struggle with deciding where to put an entry. I just think that many changes can't be easily categorised as either being There are multiple solutions to the problem of merging the current two locations. We could even do something where we keep the |
Yeah, right now we're duplicating everything everywhere 😄 Actually if you check the whatsnew for 2.5 before hippo91 and myself became release manager what is in whatsnew is really a small summary of changelog. We just had a lot of other things to take care of at the time and inadvertently created the habit of duplicating the changelog in whatsnew all the time. That's why we need to define what we want to do now (before 2.15 so the 2.15 changelog is the new example to follow, and can be enforced by CI checks + label chosen by maintainer like in black). I think we should not document simple refactor or small internal change. I.e. for the label documentation and maintenance we do not add any changelog, at all. For the API changes and deprecations, it should be in the dev facing changelog. For the dependency label we probably need to separate dev dependency from pylint's actual dependency that will affect installation alongside other libs (user facing), dev dependencies (dev facing), and from pre-commit dependency (really not important for anyone). I think that the user facing changelog should only be changes that will modify something that will affect you when you install pylint or launch pylint with Dev only. The only one where it's ambiguous imo. But there was no way to use this priority in any pylint, options, dev facing too. Dev only. Dev only. Dev only. This is probably something we should have discussed in #5728 before I create 5 MRs 😄 The need to separate user guide and dev guide - while it make sense in itself, because right now everything is mixed up and impossible to follow- stem from the fact that I wanted to not have to merge changelog and whatsnew for older changelogs but I still wanted a clear rules for new changelog in the future. |
See my proposal in my last comment: I don't think we should do something just because we have to deal with a legacy format of the changelog. Let's start writing the changelog in our preferred format and worry about how to store the old changelogs afterwards. I wouldn't mind having a sentence: "Pylint's changelog format changed after 2.x. Therefore, for older versions there are two related but different changelogs which can be found here > link to changelog archive". Or something like that... |
Reorganizing the doc is a good thing in itself too. and it's better to have a clean doc for 2.14 because it's the reference in read the doc (but we could cherry-pick it on maintenance/2.14 too when the patch become the reference and only do the changelog change during the beta). But let's just apply #6641 (comment) for this MR first :) |
Co-authored-by: Daniël van Noord <[email protected]>
|
Can't merge yet I did not apply #6641 (comment) yet |
Co-authored-by: Daniël van Noord <[email protected]>
Type of Changes
Description
Move the messages documentation to user guide and do the proper redirection.
Small reviewable part of #6589 and follow-up to #6613, #6622 and #6628