Refactoring public methods should be managed as major changes
See original GitHub issueThe refactored modal plugin method breaks backward compatibility https://github.com/Dogfalo/materialize/commit/4984e2391fa7ce428d77910c2656835c021d11be#diff-452a8aa82569876ba89deba84331011cL183
$('.modal').leanModal(); --> $('.modal').modal();
So the release version should be incremented as the npm docs recommend https://docs.npmjs.com/getting-started/semantic-versioning
Issue Analytics
- State:
- Created 7 years ago
- Reactions:13
- Comments:18 (4 by maintainers)
Top Results From Across the Web
Refactoring: This class is too large - Martin Fowler
Following the principle of tiny steps, I'll move just two methods (a public method and a private method called by it) before I...
Read more >Refactoring, a simple example - UNC Computer Science
Refactoring is a technique to improve the quality of existing code. It works by applying a series of small steps, each of which...
Read more >What Is Refactoring? - DZone
Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior- ......
Read more >Methods Should Be Public - Wiki
Methods can be public, protected, private or have package scope. Methods should be public unless they break the ClassInvariant. Proponents of having only ......
Read more >7 Code Refactoring Techniques in Software Engineering
These long methods make your code extremely hard to understand and hard to change. The composing method is mostly used in these cases....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@NitroBAY and @Levino can you be a bit respectful of the hard work that maintainers do?
Everyone makes mistakes, and actually, this one was no so very hard to find and fix for you.
Maintaining an open source project is a source of constant abuse from ungrateful users. Some toxic users start thinking that you’re under obligation to give your time for free and that’s very disappointing.
I’m leaving here two links, I hope both of you can read them and better understand the consequences.
https://www.reddit.com/r/programming/comments/5c3f7q/brett_cannon_why_i_took_october_off_from_oss/ http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering
It was an unfortunate oversight. We are still actively maintaining it, but our time is spread thin at the moment. In the near future, my time will be more free and I will put more effort into Materialize. I apologize for the error in versioning and I’ll be more careful next time.