RepRapFirmware 3.0RC1 released

garyd9

Is this in a "RC" state for the older Duet2 boards as well as newer Duet3 boards?

Thank you
Gary

dc42

@garyd9 said in RepRapFirmware 3.0RC1 released:

Is this in a "RC" state for the older Duet2 boards as well as newer Duet3 boards?

Thank you
Gary

Yes, it's for Duet WiFi, Ethernet and Maestro too. But not for Duet 06/085 because they have insufficient RAM to run both RTOS and networking easily.

dc42

A note for users of Duet3+Pi: you can upgrade to this release and still use the existing DSF if you wish, but you wont be able to downgrade (or upgrade again) except by using Bossa, until you have DSF 1.2 on your Pi.

jay_s_uk

@dc42 How long does it take to appear through normal update channels?

c310

@dc42 said in RepRapFirmware 3.0RC1 released:

DSF 1.2 on your Pi.

what us DSF on Pi ? i just got Pi and curious what it can add to my favourite duet

A Former User

Great to see RRF3 maturing, seeing as this is RC1 does that imply the conditional g-code won't make it to the first stable release, or did I miss it on the whats new page?

c310

that includes DWC 2.04 on GitHub there is only 2.03 with some parts of 2.04
What is the way to find language file(s) and make some fixes there?
how to compile it afterwards ?

thanks!

dc42

@bearer said in RepRapFirmware 3.0RC1 released:

Great to see RRF3 maturing, seeing as this is RC1 does that imply the conditional g-code won't make it to the first stable release, or did I miss it on the whats new page?

Release 3.0 won't include conditional GCode, but it does include some important preparation for it. I have already started work on 3.01.

fma

David, could it be possible to change the revision numbering and the way releases are managed?

I suggested in another thread to use a.b.c: 'a' for major release (3, here), 'b' for minor release (0, here), and 'c' for bug fixes.

Currently, installing a new release for bugs fix introduces new features, so potentially new bugs: this is not a good thing. One should be able to dissociate bugs fix and new features...

So, after the current release, which should be named 3.0.0, the next one should be named 3.1.0 (not 3.01). And bugs fix should go into 3.0.x (then in 3.1.x...)

Thanks.

Danal

@fma said in RepRapFirmware 3.0RC1 released:

And bugs fix should go into 3.0.x (then in 3.1.x...)

As we discussed in other threads, the above snippet is the flaw in this scheme. It requires re-integration feature to bug releases. Which takes time from a fixed resource.

We are always going to disagree on this... therefore, I won't repeat the entire conversation. I'll just state that there are differing perspectives in the user community.

fma

Sorry, I missed that conversation; could you point it out?

There are maybe differing perspectives in the user, but as RRF and Duet3 will be more and more used by high end printers, and by pro companies, introducing new bugs when fixing ones is a big concern...

A Former User

@fma said in RepRapFirmware 3.0RC1 released:

but as RRF and Duet3 will be more and more used by high end printers, and by pro companies, introducing new bugs when fixing ones is a big concern...

As someone who uses major.minor.bf for 3 decades, I'll just add that this does not prevent regression bugs. It is more reflective of the release process than anything else. The only thing that solves regression bugs is testing, no process and especially no version scheme will help there.

Danal

@fma said in RepRapFirmware 3.0RC1 released:

Sorry, I missed that conversation; could you point it out?

Can we have a revised release process?

My humble apologies for saying "We will always agree to disagree...". It was not you @fma; in fact you never posted to that thread.

Therefore, let me rephrase:

There are perspectives in the user community that the overhead of merging a "bugfix only" N.0.N into N.1.0 would yield a negative return when implemented by a very small (almost one man) development team. We'd prefer to stick to the current arrangement.

dc42

Some of you may not have have noticed that I did a 2.05 bugfix release, at the expense of delaying the 3.0RC1 release which was almost ready.

Synapsis

I did and thank you for that bug fix, but I do have a question. For us "home users" is it better to stay with 2.05 or update to 3.0RC1 seeing thing are very different in the way things are set up.

Danal

@dc42 said in RepRapFirmware 3.0RC1 released:

Some of you may not have have noticed that I did a 2.05 bugfix release, at the expense of delaying the 3.0RC1 release which was almost ready.

I did notice! And thank you.

At the same time, I believe a 2.xx bugfix interacting with the schedule of a 3.xx release is somewhat different than a regular practice of (in order):

3.00 initial release with however many RCs, not shown.
3.01 bug
3.10 feature (and fork)
3.02 bug (on 3.0 base)
3.03 bug (same)
3.13 (integrating 3.0x and 3.1x)

It is the hours that go into that last 'integrating' line that are my concern. Those hours simply disappear from the pool that advances both fixes and features. Factually, they slow things down.

Numerous industry studies show that within software projects that continue to evolve, 80 to 90 percent of fix code hits prior fix code, not base or feature. If that metric is accepted as fact, then fork separating and later re-integrating really accomplishes very little or nothing toward stability.

Therefore, I continue to advocate that a single code path, without multiple fork and re-integration, is proper engagement mode for very small development teams

Large team? Whole different set of answers. DevOps continuous integration, forked bugfix releases, production patch hotfixes, lots of things apply to large teams that just don't apply to very small teams.

Of course, this is all just a fun discussion. The development philosophy is ultimately up to DC42.

Phaedrux

@Synapsis said in RepRapFirmware 3.0RC1 released:

I did and thank you for that bug fix, but I do have a question. For us "home users" is it better to stay with 2.05 or update to 3.0RC1 seeing thing are very different in the way things are set up.

In my opinion, most users should stick with the RRF2 for the time being unless there is a feature of RRF3 that you really want. At least until RRF3 has been more fully developed and tested and becomes the main release. Besides that, the effort required to convert from RRF2 to RRF3 is (currently) not trivial. So unless you like to be on the bleeding edge and like testing firmware and submitting bug reports and understand that's what you're getting into, best to stick with 2.05 for now and print happily.

dc42

@Phaedrux said in RepRapFirmware 3.0RC1 released:

@Synapsis said in RepRapFirmware 3.0RC1 released:

I did and thank you for that bug fix, but I do have a question. For us "home users" is it better to stay with 2.05 or update to 3.0RC1 seeing thing are very different in the way things are set up.

In my opinion, most users should stick with the RRF2 for the time being unless there is a feature of RRF3 that you really want. At least until RRF3 has been more fully developed and tested and becomes the main release. Besides that, the effort required to convert from RRF2 to RRF3 is (currently) not trivial. So unless you like to be on the bleeding edge and like testing firmware and submitting bug reports and understand that's what you're getting into, best to sticktwith 2.05 for now and print happily.

@Phaedrux has summed it up perfectly.

gtj0

Oh boy! A semantic versioning discussion and release process!!! COUNT ME IN!

OK, so here's what we do at Asterisk.
Assuming the current RRF major version is 3 and the next will be 4...

We start with 2 branches, "3" (current), and "master" (anything targeted for 4). With no prior history, "master" and "13" are equal.

We start with a "3" branch where all development goes, bug fixes and new features that are slated for major release "3". Commits are also cherry-picked to "master".
When we'd create the first RC of "3.0" (3.0.0-rc1), so we'd create branch "3.0" from "3", tag it "3.0.0-rc1" and release from it.
If there are no issues with rc1, we tag that same commit in the "3.0" branch as "3.0.0" and release it.
Meanwhile development continues in "3".
If there are issues with rc1, the fix is committed to "3" then only that commit is cherry-picked to "3.0" and rc2 is cut.
This way the ONLY difference between rc1 and rc2 are fixes for issues found in rc1.
Meanwhile development continues in "3".
If we discover a critical bug that needs to be released quickly, the fix is committed to "3" and cherry-picked to "3.0".
If there are other critical fixes, they are also cherry picked to "3.0".
We then create a release (skipping rc/beta) of "3.0.1" which ONLY has the critical fixes.
Meanwhile development continues in "3".
When it's time to create "3.1" it's the same process.

All thew while all commits in "3" are cherry-picked to "master" so "master" is always up to date with "3" plus it has any development that is slated for the next major release.

When we start thinking about a new major version, we create "4" from "master".
Assuming "3" is still the current release, from here on, any new commits are cherry-picked to both "4" and "master". New stuff for "4" also goes into "master" and any experimental stuff for the future goes only in "master".

It sounds complicated but we use Gerrit so the cherry-picking is easy.

I'm not saying all of that stuff should be done here of course. I just wanted to highlight the differences between release versions. Also, this scheme would require that commits contain only 1 functional change and that'll be a big change for both @dc42 and @chrishamm .

I do believe though that as the user base picks up with the Duet3, RRF and DSF that changes will ultimately have to be made in the release process as well as the issue reporting process or customer perception will suffer.

@dc42 and @chrishamm , Welcome to the "real" Open Source world.

dc42

Sounds good; but in trying to apply the same fixes to RRF 2.04 and RRF3beta12, I found cherry-picking left such a mess (because the code had diverged so much between the branches) that it was better to copy across the changes manually. In doing so, I spotted that one of the fixes I had done in 3.0beta wouldn't work in 2.04 anyway. Cherry picking commits would work OK if nothing had changed in/around the code that the bug fixes were applied to, and the bug fixes didn't interact with other code that was different between the branches.

Either way, applying the same fixes to more than one branch involves a lot of extra work, especially in testing. That's why I try to avoid it. If I had an army of users running tests, it might be different. Even better from my POV would be for me to work just on the next release, and for someone else to pick up fixes from the branch I work on, back-port them to the previous stable release, do the tests, and do a patch release.