Time for Marlin 2.0 release?

[thinkyhead]

Is Marlin 2.0.x ready to take over and become the new current release?

There are very few PRs in the queue at this time, and many of those are now being targeted first for the bugfix-2.0.x branch. I've tried to make sure that the bugfix-1.1.x and bugfix-2.0.x branches are in parity with each other, and the slow, systematic approach has worked well. But, it's extra work to keep up with both, and with AVR stable in 2.0.x it feels mostly redundant.

Considerations

• AVR is just as mature & stable (if not undermined by the HAL) as in 1.1.x.
• If 32-bit platforms are still partly or completely broken, we can simply describe them as being at various stages of completion distinct from the AVR support.
• We could stick a version on the HALs to designate which are alpha, beta, etc.
  • For example: Marlin AVR 2.0.1, Due 2.0.1-b2, LPC 2.0.1-a4, etc...

Marlin 1.1.x Maintenance Mode

The bugfix-1.1.x branch can continue to receive any new features and bug fixes that go into Marlin 2.0.x, but in the long term it will be retired. We can designate that all new features should go to Marlin 2.0.x first, and only added to 1.1.x if they seem useful (or easy) to do. Although it can be left open to allow work to continue in the 1.1.x branch for a while, the natural tendency will be for most attention to go to the 2.0.x branch and 1.1.x will naturally retire.

Right now applying patches to both versions is easy, because there hasn't been any divergence in core code, but as APIs change and mature, it will be less fun to back-port to 1.1.x. So, the sooner we transition, the better…

Todos, Quibbles, Caveats

What, if anything, is currently blocking 2.0.x from being ready for the world? Let's fix what we can, make a list of what still needs work and add that to the README, and try to push this out in its as-yet-unfinished form by —say— November 1…?

[p3p]

The main thing blocking the AVR 2.0 platform is the Arduino builder issue (as far as I know I have no idea how tested the platform is), we will get a lot of issues relating to broken builds until that is fixed by them.

As for the 32 bit there are a few things I've noticed in the last few days to do with the timer type defines and a few places in stepper.cpp that has code paths (depending on config) that still use AVR specific things, also the minimum stepper pulse code is using the wrong timers ticks per us, but overall the general part of the HAL seems to be getting there.

LPC1768/9: when you go outside a default RAMPS build and need general i2c spi, serial there probably will still be issues (though getting better), clock setup still needs to detect lpc1769 and set the clocks properly. I'm going to be generalising the pinmapping as it isn't clear that all LPC1768/9 boards use the Re-ARM mapping as it makes no difference what number points to what port/pin.

[alexxy]

I run printter with Dondolo extruder on AVR (MKS gen 1.4) using bugfix-2.0.x

[Roxy-3D]

November 1st might be pushing it a little bit. I would like for the v2.0.0 release to have better support for the Re-ARM board. I feel we should have 'almost complete' support of the feature set on at least one 32-bit board. And it would be really good to have fully checked out native support for the real Smoothieboard.

Right now, the BabyStepping doesn't work in the 32-bit versions. M100 won't compile and link because we haven't done the work to identify the equivalent names for things like __BSS_END and __BRK_VAL. Pretty much, turning on strange options causes problems in the 32-bit code.

It would be a mistake to release the current code as v2.0.0 without getting the 32-bit stuff more checked out. How about we do a 'feature freeze' on v1.1.x and get more people using v2.0.0? And when we have a 32-bit reference platform that is more checked out, we circle back and have the discussion about whether we are ready to release or not?

The big problem is there are a lot of people with 32-bit boards running Smoothieware. If they hear Marlin v2.0.0 supports 32-bit some number of them are going to dive into the pool head first and be sorely disappointed by what is currently there. We are better off waiting a few extra weeks and getting everything nicely polished.

[teemuatlut]

How about we do a 'feature freeze' on v1.1.x

We've had a feature freeze since June.

I'd say release v2.0 as soon as we're confident in the Re-ARM and AVR platforms to work reasonably well. I want to see the feature freeze end and also get rid of the two parallel branches.

[Roxy-3D]

We've had a feature freeze since June.

It would be very easy to disprove this statement.

I want to see the feature freeze end and also get rid of the two parallel branches.

Yes. Everybody wants that to end.

[p3p]

@Roxy-3D as long as the AVR 2.0 platform works then maintaining 2 branches is a lot of extra work (for @thinkyhead) for no gain, If each platforms level of functionality is very clearly stated I don't see an issue with the release (other than the Arduino build issue for AVR).

Right now, the BabyStepping doesn't work in the 32-bit versions. M100 won't compile and link because we haven't done the work to identify the equivalent names for things like __BSS_END and __BRK_VAL.

Didn't know about the M100 issue, __bss_end is a standard linker define so is available (can be fixed with a define) but __brkval is specific to the AVR malloc implementation, we could probably work around that with an sbrk(0) call but I'm not familiar with what AVR do.

Have you checked the pin for activity when trying babystepping?

[Roxy-3D]

but __brkval is specific to the AVR malloc implementation, we could probably work around that with an sbrk(0) call but I'm not familiar with what AVR do.

Actually... Marlin used to do malloc()'s but there should be no malloc()'s in the code right now. It maybe we need a reference to malloc() in the M100 code to pull in that symbol. It should not be hard to get going. And in fact, M100 is only for developer types anyway. But my point is a few extra weeks (4 or 6 weeks) to get things more polished would make the release much more stable.

I know it is a lot of extra work having two branches. That is why I suggested we do a feature freeze on v1.1.x and only put new stuff into v2.0.0. And that extra activity, and new features might help us get some extra test time on it.

Have you checked the pin for activity when trying babystepping?

No, I got side tracked. I'm chasing down a weird problem right now. That Max7219 8x8 LED Matrix had its 3 control signals connected to the ethernet port. It works just fine. Right up until I do a bunch of Z-Axis movements. It gets confused when that happens. It is almost like the Z-Axis movement is toggling pins on the ethernet port. I don't really believe that. But that is what it looks like.

I just finished moving the 3 control pins to the second Extruder on the RAMPS board. I'm just trying to get it working again. I was going to see if the LED Matrix still goes crazy. If it does... I'm wondering if we have to make the WRITE() macro atomic. I'm not far enough into it to know that is happening. And I don't have a logic analyzer which would be a big help. But I'll have more information soon...

UPDATE: Even driving the Max7219 8x8 LED Matrix from different pins (the 2nd Extruder), I see the corruption. I'm going to make the pin WRITE() macros atomic and see if that helps.

[Phr3d13]

can someone help me get anet a8 sd related issues sorted before 2.0 release?

[thinkyhead]

Good feedback, thank you. The main concerns are all reasonable.

• As @alexxy points out, the AVR code is up to par with 1.1.x, so all current 1.1.x users could migrate immediately without any impact. If it's truly dangerous or useless to build some of the other architectures then we should stick an #error at the top of the problematic HALs (or the features that are broken) to prevent using them at all unless you (brave developer) comment out the line. Anyway, this is just a thought… Since Marlin is distributed as Source Code, we might as well stick "Help Wanted" ads into these #error messages and see who shows up with patches.
• As long as we can build all HALs in PlatformIO, then I think that's OK for now. I understand there are questions about how best to target both the Re-ARM and MKS SBASE, and I concur with @bobc that it's best to set a #define in the pins file or use #if MB(MKS_SBASE) to handle any differences between them, splitting up into more files only if needed.
• For Smoothieboard users, the platform we need to support best is Due (SAM3X8E), and specifically to provide a Smoothieboard pins file. Other SAM3X8E options are currently covered, so Marlin should presumably work on that hardware as well as on RADDS or RAMPS4DUE. From what I can tell, this is the most complete HAL currently after AVR, mainly due to its strong IDE support.
• After "feature freeze" was announced, it took me awhile to get to a point where PRs were at a manageable volume and I could focus the needed attention on the refactor — which took about 2 weeks of effort. Some PRs were incorporated during that period and folded into the refactor to keep the docket moving.
  I understand that the 2.0 HAL work is going to take an indeterminate amount of additional time and testing, and in the meantime, of course PRs and bug reports will continue to arrive. The "embargo" is still essentially in effect, because I know we all want to move to 2.0.x pretty soon, so nothing "major" will be merged right now, but the moratorium has been relaxed since the refactor so that the Issue Queue can get some attention, longstanding bugs can get fixed, and people don't feel too neglected during this HAL development phase.

---

Level Up…

I don't want to leap without a strong consensus, but I don't relish doing this dual-integration work for a whole lot longer if there's a way we can put 2.0 out as the current AVR and common code release. I don't think we need to remove the incomplete HALs as long as we're clear they are at alpha and beta stages.

If we further mitigate all potential confusion about the completeness of these HALs by inserting #error messages to strongly warn users that they are still in-development, I think that would be enough to secure 2.0.x from n00bs. I know that in the past we set a precedent by doing RC releases, but I think that would just drag on, and… simpler is better (which is why I chose a Performa over a Quadra), so just going for it with 2.0.0 would be my bold and sassy choice. We can make it clear in the front-facing README that we have differing levels of confidence in some HALs and some features, and that if you use them you're a beta tester, but this is the shape of things to come.

Do you think we'd get more testing and feedback this way, and shake out the bugs? Maybe some of the vendors that still hack Marlin 1.0.2 would stop and take some notice… What else would you suggest to make 2.0.x safe for public consumption?

[teemuatlut]

In addition to #error messages on features not supported on a specific platform, it might also be useful to have a #warning Platform is still in beta testing! message for certain unfinished HALs.