-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Community Question: Breaking Changes and Version 2! #190
Comments
Thank you for this library!!! After a break of almost 8 years, very few people will even notice the revival and this question. 🤣 But please carry on! |
@Georg-Git 10 million downloads a week on npmjs - so people will notice |
Of course - when the breaking changes will hit the npm fan. 😉 But I really appreciate the new team's efforts!! |
An important and widely distributed library for compression, And when asking for a non minified file at the end of the new build process of the upcoming version 2 this request was blocked by the new collaborators. 😏 I hope everybody had read the news about the backdoor in XZ Utils: Interesting parallels.... @pieroxy: 😉 EDITED: Otherwise I would have liked to take this even further by pointing to the recent issue that Chrome is already giving a virus warning when using LZ String: #239 😊 Now seriously: Especially out of respect and gratitude to @pieroxy for this repository, I would like to avoid leaving unjustified suspicion in the room. Also, I am sure @karnthis will prevent anything like that. 😉 As already written above only a few people had taken notice of this thread after an 8-year break. Therefore, I will delete this comment soon - and wish the new version much success. |
@Georg-Git Releases are planned to be directly from the Github Actions process, as in having no ability for any individual (except @pieroxy) to make a release directly. Currently you have opened and commented on several threads without having any real understanding of the open source community or apparently the npm architecture. I am very well aware of your behaviour and suggest you (and any other readers of this comment) watch this 2008 presentation from Google https://www.youtube.com/watch?v=-F-3E8pyjFo (it really needs the entire hour to be watched to understand properly). That suggestion was answered, and is as such closed. The source code is all here and anyone can build and test it in an identical way. |
@Georg-Git please don't delete your comments, they are an important part of the discussion and future readers will want to reference this down the road I'm sure. Now to your point about a non-minified version. While I understand where you are coming from and in principle I agree transparency is critical, building a non-minified file doesn't achieve that and actually opens doors for greater harm. It is quite easy to build a minified file that has little or nothing in common with a non-minified file from the same build process, but now everyone feels safe and secure because they can review the non-minified file, leading to lax security practices. We want to encourage sustainable best practices and not foster a false sense of security. |
@karnthis Thank you - far better explanation than I gave there! |
@Rycochet You should do like keep everything existing remain unchanged. no need to have any breaking change. for example, Even the existing users suddenly updated the script to latest version, there should have no change as they do not turn on the setting. |
I completely agree with @cyfung1031 in that there are plenty of ways to make the change non-breaking. That said, the fact that the Base64 is buggy should not bother anyone. The server side ports of this lib already handle the bug and there is no harm done. And the fact that it's proper Base64 is irrelevant Moreover, the That said, I understand the urge, it's itching me as well :-) |
@Georg-Git Nothing here is done in my name, you must be confused. People own their stuff and no one claimed to have done anything in my name. |
We have several breaking changes that we could make to fix things (for instance #110), and need to decide what to do about them, so asking the community for feedback. At around 10 million weekly downloads we need to make the right decision for the future!
We are getting close to version 2 being ready for prime-time release, which has one major change1 in access for it, but not in the behaviour of the endpoints (or at least not in a way that should break anything getting encoded).
There are three basic choice, please react to this post - and comment if you want to say something:
compressXyz_legacy
for compatibility.compressXyz_fixed
for correctness.Note
We have a far better test suite, and it is being designed so that implementations in other languages can test against it too, so we will hopefully get a compatibility table if people write command-line wrappers for them!
Footnotes
The old code had
require("lz-string/lib/ls-string.min.js")
as an entry point, the new code isrequire("ls-string")
(or equivalent based on your language / access of choice) - this will force people to actually look and see why they can't simply update to the latest version transparently. ↩The text was updated successfully, but these errors were encountered: