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?
Testers and bug catchers needed! Help contribute to Free Software development by testing pre-release versions.
2 posts • Page 1 of 1
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.
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.