Marlin: What needs to happen to freeze Bugfix-v1.1.x ?

[Roxy-3D]

What needs to happen to freeze Bugfix-v1.1.x ?

My personal opinion is Bugfix-v1.1.x is pretty good. It will always have some number of problems.

How about we freeze it very soon? Doing 2 Pull Request for any change is hard on the developers. Let's just have one Pull Request needed to do a change?

Opinions are very welcome. I'm just stating my opinion. As a community, we need to do what the community needs. If any of you see this differently, please speak up!

[thinkyhead]

Well, first it needs to get existing bugs patched up and have a 1.1.7 release. I agree it's pretty good, and from what I see there are just a few not-too-major bugs to clear up. I'd like to do testing and shake out any glitches in the matrix tonight, and aim to get that release out. I've already written up the release notes.. At that point, if we want, we can shift all focus to the 2.0 branch and only patch bugs — no new features — in the 1.1.x branch.

[Roxy-3D]

At that point, if we want, we can shift all focus to the 2.0 branch and only patch bugs — no new features — in the 1.1.x branch.

[teemuatlut]

I'd like to see the release of v2.0 as soon as possible. While we may have some initial issues, we can always do some quicker and smaller hotfix releases afterwards. And in the event that a feature is completely broken and unusable, we always have the 1.1.x tags. Or the user can use the latest commit if a fix has been merged but not yet released.
The important thing is that we get out of this limbo state where everything is done twice.

[Roxy-3D]

It looks like we have consensus...

[psavva]

It will be encouraging to know the new features don't need to be implemented in 2 codebases...

The sooner 2.0 is released and 1.x has a feature freeze, the better.

Just my 2 cents..

[Roxy-3D]

I'm thinking we need to hurry up and freeze bugfix_1.1.x. I have a number of features I want to add, but I don't want to do it in two code bases. I think there are other people that are holding back on contributions for the same reason.

Even if bugfix_1.1.x isn't ready to lock down... Can we stop adding features to it and do just bug fixes? Will that cause problems for anybody? Just doing that should break the log jam.

[teemuatlut]

@thinkyhead Are we doing any 1.1.x releases before 2.0.0?
There's been an increase in TMC related bug reports and some may require fixes or just additional debugging capabilities. I'd like to add these in but am hesitant because I don't know if there's gonna be any more versions.

[Roxy-3D]

I'm declaring the UBL feature set complete for v1.1.x

I am working on a number of improvements that require a lot of testing and it will be simply too much extra work to do complete regression testing in both branches. New UBL features will only be added to the v2.0.0 branch. The items I'm working on are:

• Fast G26 Mesh Validation Pattern. It doesn't look as nice as the current pattern, but it prints much faster.
• All Mesh Tilting to use the same incremental Least Squares Error routines. With a little bit of luck, multiple Mesh Tilts should converge on the same solution when the work is done.
• Ability to interactively edit Mesh Points outside the Delta Printable (and Probable) Radius. This should make it easier for the Delta users to get well tuned Mesh's that give them perfect adhesion even at the edges of the bed.

[thinkyhead]

Let's call 1.1.x feature frozen _now_ and we can make sure new feature PRs are all targeted to 2.0.x only going forward.

I'm planning to do one more 1.1.x release to patch any leveling and jerk/planner issues that still remain. I'm debugging ABL in earnest tonight, and through the concerted efforts of @Bob-the-Kuhn, @Sebastianv650, and @AnHardt it looks like we might be narrowing in on the jerk and block joining issues.

[Roxy-3D]

Let's call 1.1.x feature frozen now and we can make sure new feature PRs are all targeted to 2.0.x only going forward.

Ok... Agreed! But let's get UBL working again in v1.1.x. Setting buttons=0 makes it so the Press & Hold functions to terminate G29 P2 and G29 P1 don't work.

  void lcd_quick_feedback() {
    lcdDrawUpdate = LCDVIEW_CLEAR_CALL_REDRAW;
    buttons = 0;
    next_button_update_ms = millis() + 500;

at a minimum needs to be changed to:

  void lcd_quick_feedback(const bool clear_buttons) {
    lcdDrawUpdate = LCDVIEW_CLEAR_CALL_REDRAW;

    if (clear_buttons)
      buttons = 0;

    next_button_update_ms = millis() + 500;

    // Buzz and wait. The delay is needed for buttons to settle!
    lcd_buzz(LCD_FEEDBACK_FREQUENCY_DURATION_MS, LCD_FEEDBACK_FREQUENCY_HZ);
    #if ENABLED(LCD_USE_I2C_BUZZER)
      delay(10);
    #elif PIN_EXISTS(BEEPER)
      for (int8_t i = 5; i--;) { buzzer.tick(); delay(2); }
    #endif
  }

I have it fixed on my local machine along with the G29 J mesh tilting... But right now, UBL is broken on v1.1.x. I'm not really ready to do this in a clean way... But I'll commit the changes so you can see what was broken. Please check out: https://github.com/Roxy-3D/work

PS. Incidentally... The changes that broke G29 P1 and G29 P2 were not all bad. The changes made it so G26 did not need a 'Press and Hold' to terminate the printing of a Mesh Validation Pattern. A simple click was enough to immediately terminate the G26 which is a good thing. That is preserved in the changes at: https://github.com/Roxy-3D/work

[thinkyhead]

Setting buttons=0 makes it so the Press & Hold functions to terminate G29 P2 and G29 P1 don't work.

@Roxy-3D — I don't know why this should suddenly matter. The line buttons = 0 has been present in lcd_quick_feedback for a couple of years.

There is another recent change, however, that may actually be breaking your click-and-hold testing technique. Most code that processes a click now calls use_click which clears lcd_clicked immediately. Previously, lcd_clicked was only cleared after returning from the screen handler or other code that processed it.

You should revisit your click-and-hold code and investigate how the LCD code is breaking it, with an eye towards the use_click function as your first suspect. It certainly can't be due to the buttons = 0 line unless you're now calling lcd_quick_feedback where you weren't before.