Slic3r
Slic3r copied to clipboard
slic3r
It's been over 2 years since a stable release, and hence release notes
I don't actually care for the concept of stable releases, but a(n occasional) summary of what's new/changed that doesn't require reading the commit logs would feel nice :|
I do care for stable releases. I need to recommend slic3r to some people, and I can't do that with a 2-years-old table release.
I would like slic3r to have updated stable releases as it still relies on perl and perl dependencies are a mess to manage in most distributions so compiling Slic3r every time can be a pain. If Slic3r had more stable releases, i'm sure it would appear in the official repositories in Arch Linux and many Arch users (along with some other linux distro users i guess) will agree on the fact that compiling Slic3r isn't something we all like. I know, the AppImages do exist, but as shown in issue #5013 we can't always rely on them either...
@lordofhyphens Thanks, so unstable release it is. So there is no rc/beta planned for now?
I doubt I would ever have interest in a "rc" or "beta" release of Slic3r.
Given that most commits are (and should be) backed up by tests and fixes go through the PR process, the cost of doing so is more than the benefits.
On Sat, Oct 31, 2020, 2:36 PM Arusekk [email protected] wrote:
@lordofhyphens https://github.com/lordofhyphens Thanks, so unstable release it is. So there is no rc/beta planned for now?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/slic3r/Slic3r/issues/5015#issuecomment-719978068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHYCT253YQFIBTZE7MNHDSNRRNRANCNFSM4QPHUSTQ .
Even without setting a whole schedule now, could it not be possible to do a feature freeze at the moment and go through a bug fix only phase? just call it 1.4.0 or something. Although we don't really "fix the problem" of not having release management, but can at least bring the "latest release" to be more recent. Some people think slic3r is dead / abandoned because they only go by whatever the date says in the Releases box (regardless if it says pre-release)
What about just tagging master HEAD at some arbitrary point every month, without maintaining it? Current latest release is not maintained either, so I see no difference from not maintaining that version or the current one. It helps packagers a lot, since they can compare numbers between distributions (e.g. Debian against Gentoo) instead of commit hashes, which they kind of have to do now.
This would be a nice idea as, even if we would all like to see a new stable release of slic3r with most recent features, the main issue here is the lack of reference points that packagers needs to do their job. Because of this more and more distributions abandonned the idea to distribute slic3r prebuilt packages, and the project is increasingly loosing visibility and interest. I like to use an open source and manufacturer agnostic slicer, I also like the progressive philosophy that always has pushed the project along with the whole 3d printing industry forward and I don't want Slic3r to become the forgotten father of many corporate backed derivatives because of a lazy and messy release management. Most people uses open source printer designs and the Ultimaker backed Cura should not be their first choice. Slic3r is far from being a dead project, but for the average unaware user who never compiled a single package by hand, a project that still needs improvements and did not receive any major update since more than two years appears obviously dead. Things needs to change if we don't want everyone to run away from a software they all presume dead.
7 janv. 2021 11:55:41 AM Arusekk [email protected]:
What about just tagging master HEAD at some arbitrary point every month, without maintaining it? Current latest release is not maintained either, so I see no difference from not maintaining that version or the current one. It helps packagers a lot, since they can compare numbers between distributions (e.g. Debian against Gentoo) instead of commit hashes, which they kind of have to do now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub[https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756043476], or unsubscribe[https://github.com/notifications/unsubscribe-auth/APAXBSHXX4ESMRBRRE6IIJ3SYWHKXANCNFSM4QPHUSTQ]. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAABHNCSVQICAgIfAhkiAAAACtJREFUeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAD4MUUgAARy2AfAAAAAASUVORK5CYII=###24x24:true###][Image de pistage][https://github.com/notifications/beacon/APAXBSEKOPFGO7DECVZPXZTSYWHKXA5CNFSM4QPHUST2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUIE5VA.gif]
Considering the build system automatically generates builds, I'm not sure I see the point of having extra arbitrary 'releases' if they aren't tied to some feature or testing schedule. Just go download the most current build. If you have a problem with it, you can see the git version in the name of the package. Submit that with the bug and it will be easy to track what version of the code resulted in that binary.
On Thu, Jan 7, 2021 at 5:39 PM TheCodeExorcist [email protected] wrote:
This would be a nice idea as, even if we would all like to see a new stable release of slic3r with most recent features, the main issue here is the lack of reference points that packagers needs to do their job. Because of this more and more distributions abandonned the idea to distribute slic3r prebuilt packages, and the project is increasingly loosing visibility and interest. I like to use an open source and manufacturer agnostic slicer, I also like the progressive philosophy that always has pushed the project along with the whole 3d printing industry forward and I don't want Slic3r to become the forgotten father of many corporate backed derivatives because of a lazy and messy release management. Most people uses open source printer designs and the Ultimaker backed Cura should not be their first choice. Slic3r is far from being a dead project, but for the average unaware user who never compiled a single package by hand, a project that still needs improvements and did not receive any major update since more than two years appears obviously dead. Things needs to change if we don't want everyone to run away from a software they all presume dead.
7 janv. 2021 11:55:41 AM Arusekk [email protected]:
What about just tagging master HEAD at some arbitrary point every month, without maintaining it? Current latest release is not maintained either, so I see no difference from not maintaining that version or the current one. It helps packagers a lot, since they can compare numbers between distributions (e.g. Debian against Gentoo) instead of commit hashes, which they kind of have to do now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub[ https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756043476], or unsubscribe[ https://github.com/notifications/unsubscribe-auth/APAXBSHXX4ESMRBRRE6IIJ3SYWHKXANCNFSM4QPHUSTQ ].
[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAABHNCSVQICAgIfAhkiAAAACtJREFUeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAD4MUUgAARy2AfAAAAAASUVORK5CYII=###24x24:true###][Image de pistage][ https://github.com/notifications/beacon/APAXBSEKOPFGO7DECVZPXZTSYWHKXA5CNFSM4QPHUST2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUIE5VA.gif ]
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756430921, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPEX7FMXVFKCXZPDNNISFTSYYZ3RANCNFSM4QPHUSTQ .
The main advantage of most linux distributions over Windows is the existence of a package manager and official package repositories. This is what allow people to update their whole system or install new apps with a single command. Nobody, especially newbies, wants to regularly install tarballs or broken appimages. If you use Windows or if you are used to compiling, don't think of this as something directly useful for you. The major problem we are trying to solve here is the fact that if there is no tag or release version ever defined for newer Slic3r builds, no packager will push it to an official distribution repo, meaning that the average user will see either no Slic3r release available or a 2 year old and buggy "stable" release. I understand that even without this Slic3r development will go on, but the interest and the community around the project will fade. Package managers are the showcase of what's available for a system, you should understand that it is not convenient to update tarballs, that appimages are very often broken on many systems and that compiling from source is not something everyone can and wants to do. The last few builds i tested are way more stable than the latest "stable" release of slic3r on every system i tried. You can just check that it builds properly as of today and put a tag on it or release it as an RC and packagers will push it to repos, empowering people to see how far Slic3r evolved the last two years. It seems there is a lack of people for release management, but if everyone continues do everything to make newcommers run away the community will continue to shrink.
8 janv. 2021 1:54:57 AM dwillmore [email protected]:
Considering the build system automatically generates builds, I'm not sure I see the point of having extra arbitrary 'releases' if they aren't tied to some feature or testing schedule. Just go download the most current build. If you have a problem with it, you can see the git version in the name of the package. Submit that with the bug and it will be easy to track what version of the code resulted in that binary.
On Thu, Jan 7, 2021 at 5:39 PM TheCodeExorcist [email protected] wrote:
This would be a nice idea as, even if we would all like to see a new stable release of slic3r with most recent features, the main issue here is the lack of reference points that packagers needs to do their job. Because of this more and more distributions abandonned the idea to distribute slic3r prebuilt packages, and the project is increasingly loosing visibility and interest. I like to use an open source and manufacturer agnostic slicer, I also like the progressive philosophy that always has pushed the project along with the whole 3d printing industry forward and I don't want Slic3r to become the forgotten father of many corporate backed derivatives because of a lazy and messy release management. Most people uses open source printer designs and the Ultimaker backed Cura should not be their first choice. Slic3r is far from being a dead project, but for the average unaware user who never compiled a single package by hand, a project that still needs improvements and did not receive any major update since more than two years appears obviously dead. Things needs to change if we don't want everyone to run away from a software they all presume dead.
7 janv. 2021 11:55:41 AM Arusekk [email protected]:
What about just tagging master HEAD at some arbitrary point every month, without maintaining it? Current latest release is not maintained either, so I see no difference from not maintaining that version or the current one. It helps packagers a lot, since they can compare numbers between distributions (e.g. Debian against Gentoo) instead of commit hashes, which they kind of have to do now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub[ https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756043476], or unsubscribe[ https://github.com/notifications/unsubscribe-auth/APAXBSHXX4ESMRBRRE6IIJ3SYWHKXANCNFSM4QPHUSTQ ].
[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAABHNCSVQICAgIfAhkiAAAACtJREFUeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAD4MUUgAARy2AfAAAAAASUVORK5CYII=###24x24:true###][Image de pistage][ https://github.com/notifications/beacon/APAXBSEKOPFGO7DECVZPXZTSYWHKXA5CNFSM4QPHUST2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUIE5VA.gif ]
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756430921, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPEX7FMXVFKCXZPDNNISFTSYYZ3RANCNFSM4QPHUSTQ .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub[https://github.com/slic3r/Slic3r/issues/5015#issuecomment-756478117], or unsubscribe[https://github.com/notifications/unsubscribe-auth/APAXBSDZCZMO2TCUCH5Y6JDSYZJV7ANCNFSM4QPHUSTQ]. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAABHNCSVQICAgIfAhkiAAAACtJREFUeJztwQENAAAAwqD3T20ON6AAAAAAAAAAAAAAAAAAAAAAAAAAAD4MUUgAARy2AfAAAAAASUVORK5CYII=###24x24:true###][Image de pistage][https://github.com/notifications/beacon/APAXBSF7DPGP5MMEWFKOQR3SYZJV7A5CNFSM4QPHUST2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFULPBJI.gif]
@alranel @lordofhyphens @foreachthing @henrikbrixandersen @hroncok @ntfshard @platsch @Samir55 @xoan there's MULTIPLE active, fully disclosed vulnerabilities in slic3r & libslic3r (note: I'm well aware some of these might be bullshit "vulnerabilities" as had recently happened to curl & libcurl, but IFF that's the case, they should received a "that's bullshit" response) AND builds are failing. (and no I don't mean the https/http issue with http://dl.slic3r.org/win/, where one can find a working but vulnerable build) Please start looking for new maintainers by adding an appropriate note to the readme instead of silently abandoning the project, It doesn't deserve that. (I won't ask you to re-pick up the work, as that'd seem highly unfair.)
How about (if they'd be interested — I had neither association nor affiliation with either) @supermerill, who appears to maintain a working fork here:
https://github.com/supermerill/SuperSlicer
There's even a branch & pull request (which appears to have gone unnoticed) here:
https://github.com/slic3r/Slic3r/tree/merill-merge
https://github.com/slic3r/Slic3r/pull/5146 (Cc @atamico who filed the pull request).
(Note: if there's been any historic social conflicts involved here, I'm not aware of any of them, so please don't take this the wrong way, I'm a completely uninvolved bystander)