RRF Version numbers and tagging

gtj0

@dc42 Would it be possible to change RRF to use a more standard major.minor.patch version scheme. It might make it easier for folks to understand what they might want to skip if they're otherwise running OK. For instance, a 3.1.0 to 3.2.0 change (with 3.2.0-RCs in between) would imply new features plus fixes suitable for production but a 3.1.0 to 3.1.1 change would imply fixes only.

Also would it be possible for you to tag CANlib, CoreNG, FreeRTOS and RRFLibraries with the RRF version that they support. This would make it easier for us folks who test and tinker to go back to known versions of RRF and get the matching library versions.

A Former User

Was a topic about a year ago or so, conclusion "possibly, not feasible" iirc but couldn't find the refrence with a quick search

A Former User

@bearer said in RRF Version numbers and tagging:

Was a topic about a year ago or so, conclusion "possibly, not feasible" iirc but couldn't find the refrence with a quick search

(not what i was looking for, but there is some discussion of the same here https://forum.duet3d.com/topic/13381/reprapfirmware-3-0rc1-released/10?_=1588434489302)

gtj0

@bearer I have a hard enough time remembering conversations from yesterday.

dc42

@gtj0 said in RRF Version numbers and tagging:

@dc42 Would it be possible to change RRF to use a more standard major.minor.patch version scheme. It might make it easier for folks to understand what they might want to skip if they're otherwise running OK. For instance, a 3.1.0 to 3.2.0 change (with 3.2.0-RCs in between) would imply new features plus fixes suitable for production but a 3.1.0 to 3.1.1 change would imply fixes only.

That's almost what we do already. We use 2 digits for the second number so that version number strings can be compared, for example it's important that 3.10 > 3.2 > 3.1. We don't currently include the .0 at the end of the version number of a new minor release, but we could do.

Also would it be possible for you to tag CANlib, CoreNG, FreeRTOS and RRFLibraries with the RRF version that they support. This would make it easier for us folks who test and tinker to go back to known versions of RRF and get the matching library versions.

Yes I could do that.

gtj0

@dc42 said in RRF Version numbers and tagging:

@gtj0 said in RRF Version numbers and tagging:

@dc42 Would it be possible to change RRF to use a more standard major.minor.patch version scheme. It might make it easier for folks to understand what they might want to skip if they're otherwise running OK. For instance, a 3.1.0 to 3.2.0 change (with 3.2.0-RCs in between) would imply new features plus fixes suitable for production but a 3.1.0 to 3.1.1 change would imply fixes only.

That's almost what we do already. We use 2 digits for the second number so that version number strings can be compared, for example it's important that 3.10 > 3.2 > 3.1. We don't currently include the .0 at the end of the version number of a new minor release, but we could do.

There are plenty of utilities that can do semantic version comparisons. Anyway, if you think that there'll be a 3.01.1 for instance instead of a 3.02 then adding the patch level to all releases will make things easier I think. I.E. 3.01.0, 3.01.1, 3.02.0-RC1, 3.02.0, etc. Easy to parse with a regex for example.

Also would it be possible for you to tag CANlib, CoreNG, FreeRTOS and RRFLibraries with the RRF version that they support. This would make it easier for us folks who test and tinker to go back to known versions of RRF and get the matching library versions.

Yes I could do that.

That would be excellent, thanks! RCs as well I hope.

Danal

To me, the bigger problem is lack of mapping from 'apt' releases to "V3.01 RC11" nomenclature.

I've been trying to decide if this is worth releasing. Looking at it tonight, I realize it should also show DWC

 ./DuetVersionsAll.sh
Expect this to take several seconds per line of output.
Note: For highest accuracy, run 'sudo apt get update' first.

duetsoftwareframework 2.1.3 contains reprapfirmware version 2.1.3-1 which is internal version 3.01-RC11
duetsoftwareframework 2.1.2 contains reprapfirmware version 2.1.2-1 which is internal version 3.01-RC10
duetsoftwareframework 2.1.1 contains reprapfirmware version 2.1.1-1 which is internal version 3.01-RC10
duetsoftwareframework 2.1.0 contains reprapfirmware version 2.1.0-1 which is internal version 3.01-RC9
duetsoftwareframework 2.0.0 contains reprapfirmware version 2.0.0-1 which is internal version 3.01-RC8

dc42

@gtj0 said in RRF Version numbers and tagging:

There are plenty of utilities that can do semantic version comparisons.

Maybe; but I am not going to waste time and precious flash memory space by adding a separate data type in the object model so that conditional GCode can compare version numbers. Much simpler to include the leading zero.

gtj0

@Danal said in RRF Version numbers and tagging:

To me, the bigger problem is lack of mapping from 'apt' releases to "V3.01 RC11" nomenclature.

Yeah, I don't use the packages because I compile and test a lot but it would make sense that the reprapfirmware package have the same version as the firmware it contained.