PrusaSlicer 2.1.0 - RC  

  RSS
jakub.d
(@jakub-d)
Member Admin

Hi guys,

We are getting closer to the final release of PrusaSlicer 2.1.0. Check out the newest release candidate, which is recommended for experienced users 😉 

The release candidate shares the configuration directory with the previous PrusaSlicer release.

What is new?

  • Translations finished
  • Linux fix
  • Bug fixes

Translations

  • Spanish, French and Italian languages are fully translated.

Linux fix

  • Linux specific build system fix: Only set SLIC3R_FHS_RESOURCES when SLIC3R_FHS is set #2646, thanks @labsin.

Bugs fixed

  • Fixed some wxWidgets asserts reporting incorrect (1 pixel off) bitmap sizes #2850.
  • Fixed a regression issue of PrusaSlicer 2.1.0-beta3: G-code preview was broken, travel paths were incorrectly classified as print paths etc. #2857.
  • Following color change issues were fixed:
    • Adding color change at the last layer did not work reliably.
    • Adding color change before the first layer has no effect, therefore it is now disabled.

Supported printers:

  • Original Prusa i3 MK3S MMU2S
  • Original Prusa i3 MK3S
  • Original Prusa i3 MK3 MMU2
  • Original Prusa i3 MK3

 

  • Original Prusa i3 MK2.5S MMU2S
  • Original Prusa i3 MK2.5S
  • Original Prusa i3 MK2.5 MMU2
  • Original Prusa i3 MK2.5

 

  • Original Prusa i3 MK2/S MMU1
  • Original Prusa i3 MK2/S

 

  • Original Prusa SL1

 

Download link:

https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.1.0-rc

 

Please report any bug here:

github.com/prusa3d/PrusaSlicer/issues

 

We look forward to your feedback!

Assembly manuals / Knowledge Base
The guy behind Prusa assembly manuals......
Posted : 04/09/2019 4:32 pm
Sembazuru
(@sembazuru)
Reputable Member

Quick clarification, please. Does this release share the configuration folder with the last stable release (i.e. 2.0.0), or with the last beta release (2.1.0-b3)?

Posted : 05/09/2019 4:26 am
bubnikv
(@bubnikv)
Member Admin

It shares configuration folder with the 2.0.0 release. The release candidate is considered to be a release quality. Let's keep the fingers crossed.

 

...
Posted : 05/09/2019 6:35 am
Sembazuru
(@sembazuru)
Reputable Member

Version 2.1.0 final has been released on github as of 2 hours ago. I haven't checked to see if the Prusa site download page has been updated yet though.

Posted : 16/09/2019 1:49 pm
Tim
(@tim-m30)
Famed Member

An RC build should be the exact same code as what is released - unless some disastrous defect is found in how it installed.  Any changes in actual code from RC to release means the RC was just another beta build and you are missing a development step. But then I only managed professional software products ... 

 

It is always wise to get more than one opinion......
Posted : 16/09/2019 2:53 pm
Sembazuru
(@sembazuru)
Reputable Member
Posted by: @tim-m30

An RC build should be the exact same code as what is released - unless some disastrous defect is found in how it installed.  Any changes in actual code from RC to release means the RC was just another beta build and you are missing a development step. But then I only managed professional software products ... 

 

There were actually two release candidates this time around. If you read the change logs on the GitHub release pages you will see there was still some bug fixing in the RC cycle (many seemed to be regression issues). So, you are right that the RCs were really beta builds, but Prusa apparently thought the RC releases were dotting "i"s and crossing "t"s from final and subsequently discovered the regression bugs.

But it really doesn't matter, does it? Semantic squabbling... 😉

Posted : 16/09/2019 3:14 pm
bubnikv
(@bubnikv)
Member Admin

> An RC build should be the exact same code as what is released - unless some disastrous defect is found in how it installed.  Any changes in actual code from RC to release means the RC was just another beta build and you are missing a development step. But then I only managed professional software products ... 

You should wear this:
https://www.amazon.com/Engineer-Shirt-Only-Negative-Feedback/dp/B078Z21HRG

 

We have to balance budget (number of developers, number of testers), release cycle duration, amount of new features, risk of introducing bugs. We are not Microsoft, our SW development budget is smaller while the release cycles are relatively tight. As we are an open source company, we are thankful to the community to help out with the testing, therefore we may risk doing less testing than for example Microsoft would do. 

 

...
Posted : 16/09/2019 3:49 pm
Tim and david.a66 liked
Tim
(@tim-m30)
Famed Member

Not following some process gets people into a trap of thinking "one more change" is okay, yet that change might have consequences no one thought of, isn't tested well, and has a significant risk the release is now corrupt.   So you have 10,000 angry customers - a situation that can be easily avoided.

The engineering team on my products was using an Agile process - and we had a monthly release cycle - rapid implementation of new features (and defect resolution) was critical.  We weren't Microsoft, but we did have a budget.

This post was modified 4 weeks ago 2 times by Tim
It is always wise to get more than one opinion......
Posted : 16/09/2019 5:45 pm
Tim
(@tim-m30)
Famed Member

I thought I should add: the improvements being made to P.Slicer are significant, and welcome.  Any criticism is meant to be constructive and helpful; not disincentive.  

It is always wise to get more than one opinion......
Posted : 16/09/2019 5:52 pm
Share:

Please Login or Register