Pylint milestones for 2.5.4 were not all fixed before the release of 2.6.0

[Pierre-Sassoulas]

Question

I've done some issue cleanup this morning and saw we released 2.6.0 due to popular demand (#3722 with 70 thumbsups in less than a month) before we released 2.5.4. Should we have released as a minor version (ie. in 2.5.4 not 2.6.0) and pushed the milestone name to 2.5.5 ? What could we do to fix that now ? Maybe we change the name of the milestone ? Move everything to a 2.6.2 milestone ? Some issues are popular, like the concurrent job problem we fixed in #3738 so this is probably going to be a recurring problem that we have no "guideline" how to fix, especially since @PCManticore is a lot less involved right now.

@hippo91 @AWhetter

[AWhetter]

Good catch. I think calling the release 2.6.0 was the right move, because we were releasing new features and not just bug fixes. Moving everything in the 2.5.4 milestone to a 2.6.2 milestone seems like a good idea to me.
I think unless we have an issue labelled as a blocker, nothing should stop us from doing a release if there's a good enough reason for it. But it means that we need to be keeping on top of triaging new issues. If we break something in the master branch and we get an issue report about it, ideally we would be marking that as a blocker before the next release to prevent us from releasing that broken change.
Perhaps we should add a step to the release process that is something like "check for blocker issues"?

[hippo91]

I agree totally with @AWhetter remarks, but shouldn't move everything in 2.5.4 to 2.6.1 milestone instead of 2.6.2?

[Pierre-Sassoulas]

You're right, I thought we released 0.6.1, but we didn't :)

[Pierre-Sassoulas]

I fixed the milestone name. The only blocker issue we have on the repo is a big one : #746. We should probably be getting saner step by step :D. Agree with the check of blocker issue to check and to use this label like this otherwise.

[Pierre-Sassoulas]

I just got the publish right on pypi I can make a release even if the tag pipeline fails now :) @PCManticore also told me this:

I suggest we publish the master branch as a minor version (2.7.0 - e.g. we could drop support for Python 3.5 if we did not do it already) and afterwards, all bugfix releases should go into their separate branches. For instance, 2.6.1 ideally should have been done into a 2.6 branch while the master could have been tagged as 2.7. This means that new checks or features could safely land in 2.7, but bug fixes and whatnot could be cherrypicked back in 2.6 branch. That's a lot of effort, I know, but it would keep the master open for future major changes without tying us to release them in a bug fix release.

I think it's making a lot of sense, especially if we need to release an old version for example here #3971. What do you think @AWhetter @hippo91

[hippo91]

@Pierre-Sassoulas i agree with that. Does it mean that we will have to merge for example 2.6.1 into 2.7 before releasing 2.7?

[hippo91]

The pipeline CI should be fixed as soon as pylint-dev/astroid#890 will be merged

[Pierre-Sassoulas]

I think we did not apply the proper git workflow this time but that untangling 2.6.1 and 2.7.0 would be too time consuming. I think we need to release 2.6.1 with the feature it has (that should ideally have been in 2.7). Or release 2.7.0 directly. And then create a 2.6.x or 2.7.x branch for cherry picking future bug fix from master. There is quite a lot of merge request to treat before release once Astroid is fixed. I think the next one would be #4077 to fix pylint's test.

[cdce8p]

I think we might need a new release of astroid as well and then bump the min required version for pylint. That would resolve some issues with __class_getitem__: pylint-dev/astroid#885, #3951

pylint-dev/astroid#886

[AWhetter]

My vote is to call this release 2.7.0. I think we're releasing too much stuff to only bump the patch number.

[hippo91]

@Pierre-Sassoulas @cdce8p @AWhetter if i undestand well i should do an astroid release : 2.5.0 and create a branch (2.5.1) that will contain only bug fixes. Thus the 2.5.1 will be the release that will come after 2.5.0 and we can make strong refactoring or develop major features for a future 2.6.0 without impacting the production version.
Am i right?
If so i will make the release ASAP.
I just have another (dumb) question : how can i check the dependencies are correct?

[Pierre-Sassoulas]

Yeap, I would just call it 2.5 instead of 2.5.1 so it still makes sense after we release 2.5.1 and start doing 2.5.2. Regarding the dependencies, maybe I did not understand the question. but pylint use astroid latest master, so pylint's test passing at release time should guarantee that astroid's dependencies are correct ?

[AWhetter]

how can i check the dependencies are correct?

I'm guessing that this is a reference to the release process documentation where it says "Check if the dependencies of the package are correct". Theoretically we might start importing a package that we don't declare in the setup.py but is defined in the dependencies of another of our dependencies and the tests would still pass. Usually this is something that would get found in a pull request and checking for it at the point of releasing the package seems excessive given how long it takes to figure out the problem and how often we actually change our dependencies.
But if I'm checking for this I grep for "import" throughout the code and check that everything that's imported is listed in the dependencies.

[hippo91]

@AWhetter thanks a lot for this explanation!

[hippo91]

I just released astroid 2.5. I hope everything is ok with it.

[hippo91]

I just created a 2.5 branch that will receive the bug fixes from master and lead to the next release (2.5.1).

[Pierre-Sassoulas]

I just released a 2.6.1 version of pylint with astroid dependencie < 2.5 to fix #4093 and opened a merge request to fix the changelog and whatsnew prior to the release of 2.7 (#4095).

[Pierre-Sassoulas]

To sum up:

Branching for major/minor version:

• master branch with all the new features for the x.y+1 version
• x.y branch for minor release where we cherry-pick bugs to release the x.y.z versions

Milestone handling:

We move issue that were not done in the next milestone and only block release only if it's an issue labelled as blocker.