Rubocop: RuboCop 1.0 release checklist

[bbatsov]

@rubocop-hq/rubocop-core I'm creating this ticket, so we can coordinate the final work needed for RuboCop 1.0. Please, add the 1.0 milestone to everything you want us to do for 1.0 (I hope there are only a handful of such tasks left) and link to any external issues that are related to the release (e.g. issues in rubocop-ast). Here's the high-level overview from my perspective:

• [ ] Release rubocop-ast 1.0
• [ ] Merge https://github.com/rubocop-hq/rubocop/pull/8490 (changes the way the badge numbers are calculated)
• [ ] Enable all pending cops

[marcandre]

Issues I'd like resolved are already in the 1.0 milestone (here and on the ast side)

[bbatsov]

@rubocop-hq/rubocop-core It seems to me we're more or less ready for the 1.0 release. We've been postponing it for a while now, but I feel we should just press the trigger at this point, as we can always find more things to improve for 1.0. :smile: I'll go over the open PRs and merge as many as I can over the weekend, do 0.90 and if afterwards we'll enable all the pending cops and go big, unless someone has strong objections for that course of action.

[marcandre]

Sounds good. The one thing I'd love to see improved before the 1.0 release is caring about the public API. I can work on finishing the #8278 on Monday/Tuesday. I also would love if we could find a solution to the mix of constants we have, some of which are Sets, some are Arrays. I think my last proposal rubocop-hq/rubocop-ast#57 is the best...
BTW, I've not been very active these last days, I'm working on a brand new NodePattern compiler, it's taking good shape, I'm quite excited about it. Not needed for 1.0 though.

[bquorning]

Are you planning to release v0.90 from the RuboCop master branch? And would that mean bugfixes are blocked until v1.0 is released, or would you maintain a “0.x” branch in parallel with master?

As one of the maintainers of the RuboCop-RSpec project, I am sure our users would appreciate waiting as short a time as possible after the RuboCop 1.0 release before we can release a compatible version of RuboCop-RSpec. However, we have quite a few changes that we need to merge and test before we can release a compatible version. It may be possible to do in a few days, but who knows…

I guess I have two more questions:

1. How long do you intend to wait for feedback from the 0.90 release before releasing v1.0?
2. Would you allow RuboCop-RSpec preparing a compatible release (v2.0) to block the release of RuboCop v1.0?

[bbatsov]

Are you planning to release v0.90 from the RuboCop master branch?

Yes.

And would that mean bugfixes are blocked until v1.0 is released, or would you maintain a “0.x” branch in parallel with master?

No, merging bug-fixes will be fine between 0.90 and 1.0, but probably we won't merge much else. I don't plan to release more 0.x versions afterwards, unless there's some strong need to do so.

How long do you intend to wait for feedback from the 0.90 release before releasing v1.0?

I was thinking of something like a week.

Would you allow RuboCop-RSpec preparing a compatible release (v2.0) to block the release of RuboCop v1.0?

I guess that depends on how much time we're talking about. It seems to me only the badge number changes is really necessary in rubocop-rspec (looking the list of changes you shared).

[bbatsov]

@rubocop-hq/rubocop-core Seems like the time for 1.0 has finally come! Lately we've mostly been fixing bugs, so I'll probably one final 0.91 release today or tomorrow and 1-2 days later we'll go for 1.0 unless someone has strong objections. There are just 2 open tickets for 1.0 - enabling all pending cops and merging the PR about the badge numbers.

[bquorning]

I assume nobody should merge any non-1.0 related pull requests between the v0.91.0 release and v1.0.0? Or maybe even a couple of days longer, to leave time for eventual bugfix releases of v1.0.x?

Update: I just realized I asked the exact same question two weeks ago 😄 Please ignore.

[marcandre]

Awesome.
Could we have a decision for 1.0 about the many constants we have, some of which are arrays, others sets:
1) leave as is
2) # @api private
3) private_constant
4) my module which auto creates a _SET variant
5) other

Again, my concern is that some external users use the current constants and we break stuff changing them from arrays to sets or vice versa.

[bbatsov]

I think 3) is my favorite right now, but as noted in the past - I don't have a strong preference on the subject. I recall the others had some concerns about 4), that's why I don't want to force it on them.

[bbatsov]

0.91 is out, so let's see what bugs are going to be reported and make the final push for 1.0! :-)

[marcandre]

I think 3) is my favorite right now, but as noted in the past - I don't have a strong preference on the subject. I recall the others had some concerns about 4), that's why I don't want to force it on them.

I created https://github.com/rubocop-hq/rubocop-ast/pull/114

For the constants in node.rb (most of which I'd like to change to sets), there are 7 used in the main gem. Should I change them to sets, and mark them @api private?

Searching 1334 files for "AST::Node::" (regex, case sensitive)

/Users/mal/rubocop/lib/rubocop/cop/lint/assignment_in_condition.rb:
   45            'Use `==` if you meant to do a comparison or move the assignment ' \
   46            'up out of the condition.'
   47:         ASGN_TYPES = [:begin, *AST::Node::EQUALS_ASSIGNMENTS, :send].freeze
   48  
   49          def on_if(node)

/Users/mal/rubocop/lib/rubocop/cop/lint/return_in_void_context.rb:
   65          def setter_method?(method_name)
   66            method_name.to_s.end_with?('=') &&
   67:             !AST::Node::COMPARISON_OPERATORS.include?(method_name)
   68          end
   69        end

/Users/mal/rubocop/lib/rubocop/cop/style/and_or.rb:
   79  
   80          def on_conditionals(node)
   81:           node.condition.each_node(*AST::Node::OPERATOR_KEYWORDS) do |operator|
   82              process_logical_operator(operator)
   83            end

/Users/mal/rubocop/lib/rubocop/cop/style/method_call_without_args_parentheses.rb:
   46  
   47          def any_assignment?(node)
   48:           node.each_ancestor(*AST::Node::ASSIGNMENTS).any? do |asgn_node|
   49              # `obj.method = value` parses as (send ... :method= ...), and will
   50              # not be returned as an `asgn_node` here, however,

/Users/mal/rubocop/lib/rubocop/cop/style/nested_modifier.rb:
   97          def requires_parens?(node)
   98            node.or_type? ||
   99:             !(RuboCop::AST::Node::COMPARISON_OPERATORS & node.children).empty?
  100          end
  101        end

/Users/mal/rubocop/lib/rubocop/cop/style/redundant_conditional.rb:
   28          include Alignment
   29  
   30:         operators = RuboCop::AST::Node::COMPARISON_OPERATORS.to_a
   31          COMPARISON_OPERATOR_MATCHER = "{:#{operators.join(' :')}}"
   32  

/Users/mal/rubocop/lib/rubocop/cop/style/ternary_parentheses.rb:
   61          extend AutoCorrector
   62  
   63:         VARIABLE_TYPES = AST::Node::VARIABLES
   64          NON_COMPLEX_TYPES = [*VARIABLE_TYPES, :const, :defined?, :yield].freeze
   65  

7 matches across 7 files

[marcandre]

Different question: my big rewrite of the NodePattern compiler is pretty mature. I have not had any comment on the new extensions I'm proposing (extend "or" and regexp) though. I'm working on a rubular.com-like app, I hope to have a working demo soon.

Should I merge it and release a v0.9, or as v1.0 or wait a bit. I'm not expecting any incompatibility, but it is a complete rewrite...

[bbatsov]

For the constants in node.rb (most of which I'd like to change to sets), there are 7 used in the main gem. Should I change them to sets, and mark them @api private?

Fine by me.

Should I merge it and release a v0.9, or as v1.0 or wait a bit. I'm not expecting any incompatibility, but it is a complete rewrite...

Let's live dangerously and merge it. We can have one extra release before 1.0 just to make sure nothing breaks.

[marcandre]

Heads up: I'll try to finish a PR to tweak the AbcSize metric asap; there's a bug to fix and I realized that a few more tweaks are necessary...

[marcandre]

I just released rubocop-ast 0.7 with the shiny new NodePattern compiler and the new bells and whistles 🎉 . I'm keeping my 🤞 in the next few days for any unforeseen compatibility issues

Constants have been dealt with too, so rubocop-ast is pretty much ready for v1.

[bbatsov]

Great news!

So, I guess we can do one more minor RuboCop release to be on the safe side and then bump both gems to 1.0 together and go big in style! :-)