Cura LulzBot Edition version numbering scheme

Testers and bug catchers needed! Help contribute to Free Software development by testing pre-release versions.
Post Reply
b-morgan
Posts: 166
Joined: Fri Aug 11, 2017 8:53 am

Cura LulzBot Edition version numbering scheme

Post by b-morgan » Thu Apr 05, 2018 4:57 pm

Can someone explain the version numbering scheme in http://devel.lulzbot.com/software/Cura2/. In the windows folder, I see versions 3.2.1 thru 3.2.x where 3.2.1 thru 3.2.x-1 have a constant date and the date/time on 3.2.x keeps changing.

Version 3.2.11 is the alpha listed in the forum announcement for the alpha. I assume that 3.2.x is an (automated?) build of the head of the repository and 3.2.x-1 was frozen at its date/time for some reason.

Assuming I'm willing to test the bleeding edge, which one should I test with? It seems that if I test with 3.2.x and report a bug, I need to also mention the date/time of the version I installed, correct? Should I be testing with 3.2.x-1 as a bug report with that version number should point to a known branch/tag in the repository?

Brent.I
Aleph Objects | LulzBot
Posts: 406
Joined: Mon Jan 20, 2014 8:21 am

Re: Cura LulzBot Edition version numbering scheme

Post by Brent.I » Mon Apr 09, 2018 7:13 am

b-morgan wrote:
Thu Apr 05, 2018 4:57 pm
I see versions 3.2.1 thru 3.2.x where 3.2.1 thru 3.2.x-1 have a constant date and the date/time on 3.2.x keeps changing.
We do have our builds set up automatically, where each commit triggers a new build. These builds will automatically be pushed to http://devel.lulzbot.com/software/cura-lulzbot/ folders (your link re-directs here.) The latest build in that directly will be continuously changing as we incorporate fixes. We than manually change the version when we feel enough changes have been completed, and begin a new round of smoke testing.

The forum post states 3.2.11 as we have completed a thorough smoke test (https://code.alephobjects.com/w/cura-lu ... moke_test/) which verifies functionality across a wide spectrum of platforms.

If you would like to stay with the bleeding edge, you can stick with the absolute latest version in that repository. Just note, it may be updated multiple times a day. Sticking one version back and checking in a couple times a week may be a more realistic approach.
b-morgan wrote:
Thu Apr 05, 2018 4:57 pm
test with 3.2.x and report a bug, I need to also mention the date/time of the version I installed, correct?
Just the version will be fine. If it is something we broke by adding in or changing, it should be pretty easy to track down our commit that caused it. If it wasn't our fault, we should be able to duplicate it across multiple versions.

Post Reply