Webmin has never broken backward compatibility in any notable way in its nearly 20 years of existence, and thus, it's never had a major version bump (well, aside from the jump from 0.x to 1.x, but that marked stability rather than breaking changes). Not breaking backward compatibility has led to some not insignificant technical debt to accrue, and slowed adoption of more modern Perl coding practices within Webmin core and third party modules.
Webmin 2.0 has the goal of paying off that technical debt in a gradual way, while still resulting in a more flexible and modern core. 2.0 won't break backward compatibility gratuitously, but won't adhere to old coding style and old practices to prevent breakage, either.
Stage 1 (pre-branch; ETA currently ongoing)
The first stage of Webmin 2.0 development is ongoing, and will continue during the Webmin 2.0 branch. Many of these changes will be committed to Webmin 1.x, and will involve no major architectural changes. These changes are more of a clean up than an upgrade.
use strict and use warnings throughout Webmin core
The first step to a modern Perl Webmin is to enable strictures and warnings throughout Webmin and every actively maintained module. This project has been ongoing for some time, and still has a few months to go. We would love help with this! It is tedious, slow, thankless, work. But, it reveals bugs (we've found bugs that have gone unnoticed for over 15 years in some cases...admittedly, it can't be a very serious bug if nobody noticed it in 15 years, but a bug is a bug, and everybody wants bug-free software), and helps us get ready for the next steps in the process.
Because Webmin development began in a time when Perl 4 was the predominant Perl version, there are still many old school Perl quirks throughout Webmin (like use of "local" instead of "my"). That has often been cargo-culted into new modules and themes by developers who aren't familiar with Perl and are just copy-pasting from whatever bits of Webmin seem relevant.
Enabling strictures and warnings makes it easy to spot a wide variety of error-prone practices; finding them is the first step to fixing them. We welcome pull requests that improve the warnings/strict compliance of any part of Webmin (please test as well as you can, as this can introduce subtle misbehaviors, even while also revealing and helping fix bugs).
Perl Critic
The next step after getting warnings/strict compliant is to make Perl Critic happy. Perl Critic is a static analysis tool for Perl code that helps spot coding practices that might result in subtle bugs. It doesn't guarantee good code, but it can help make the code more readable for both new and old Perl developers and enable more rapid development in the future. Predictable and consistent code is easier to work with.
Perl Tidy
This one is merely cosmetic, but likely useful for programmer happiness and code readability. Once we've completed the strict/warnings and Perl Critic passes over Webmin and all core modules, we will settle on a nice standard set of guidelines, and implement it automatically through Perl Tidy, by making every commit adhere to the same Perl Tidy settings (the Go community has been well-served by having a standard tool and universal set of formatting guidelines that every project follows). This will unify indentation (spaces vs. tabs), indentation width (2 vs 4 vs 8 chars), brace style (cuddled else vs. newline, etc.), sub definition style, and more. Webmin has been in development for many years, through several popular Perl styles, and it shows.
Stage 2 (post-branch; ETA 4th quarter 2016)
Once stage 1 has been completed, we'll begin work on a Modern (or Enlightened) Perl overhaul of Webmin and all core modules. This stage will be the point where we can break backward compatibility for both themes and modules, without feeling guilty. For users of third party modules, or core modules that don't make the cut for Webmin 2.0, Webmin 1.x will continue to see maintenance for several months, and will likely see security updates for at least a year after 2.0 reaches stability (so, sometime in 2018 or 2019).
Purge Old Modules
Webmin has a lot of modules. Many of them have dropped in popularity to the point of being very obscure and only having a few users. Many have been subsumed by other modules (File Manager, for example, may be a better way to achieve the goals of the upload/download module, among other things). Because of the scope of this overhaul, bringing over modules with only a handful of users isn't worthwhile; 1.x will stick around to accommodate those users. They're probably on an old OS version, anyway, and will need to stick with old Webmin, anyway, because of the next step.
Purge old Operating Systems support
Irix, Trustix Linux, United Linux, Corel Linux, Coherent, SoL Linux, Cobalt Linux, OSF1/Tru64. At least these, and maybe a few others. None of them have had releases in the past decade, and if anyone is still running them, using a new Webmin version is the least of their worries.
The benefits of purging ancient operating systems: Less surface area to test, smaller distribution, looks simpler to new developers (the size and scope of Webmin is very intimidating to new developers). And, if anyone is still using any of these systems (except in a retro or museum context), they need to be encouraged in any way possible to stop doing so.
Require a modern(ish) Perl version
Webmin currently runs on any Perl all the way back to about 5.8.4. That's a quite old version (2004!), and many modern Perl libraries won't work at all with it. It also limits our use of some modern features of the language. At this stage, we'll add "use 5.10.1" to the standard preamble of every Perl file (along with strict and warnings). This is the version of Perl shipped with RHEL/CentOS 6, and is likely to be the oldest Perl version in common use at the time of Webmin 2.0s release into stability. RHEL/CentOS 5 was the last distro to support a Perl version older than 5.10.1 and it reached end of life early in 2016, so there are no living operating systems with an older Perl than 5.10.1.
Stage 3
Increase Test Coverage
A major re-factor is big project, and it's easy to make mistakes when touching a lot of lines of code in a short time, as this re-factor will do. So, we need a better test suite than we currently have. Perl has among the best testing tools in the software development world; no reason we shouldn't be taking advantage of them. Some low-hanging fruit includes automatically checking for warnings and strictures, automatically testing every page for 50x errors, etc. It won't be possible to backtest everything in Webmin on this schedule; and it's probably not even advisable to do so. But, whenever a specific piece of code is getting a major overhaul, it is probably profitable to also write some tests before making the changes.
Improve Instrumentation
Performance is super important for a project as big and as heavily used as Webmin. Adding a performance testing harness would be a good start on making it easier to find hot spots and optimize for a faster user interface with lower CPU and memory usage. NYTProf seems to be the best tool for the job, but many other tools exist, and we'll likely want to integrate at least one into our standard test suite to spot newly introduced bottlenecks.
Stage 4 (breaking/fixing everything; ETA ?)
Mojo, IO::All, Moo, Type::Tiny, autodie, Try::Tiny?
Webmin has a huge library of helper functions built-in. Partly this is due to history; a lot of this functionality didn't always exist in the standard library or in existing well-maintained projects. It also is due to the requirement that Webmin run with extremely minimal dependencies (which isn't changing).
The Enlightened Perl project has selected a variety of recommended Perl modules that are known to be well-designed, and to improve readability and conciseness of Perl code. The ones I've mentioned specifically are things I've wanted during my own development. But, many other excellent modules are listed on Task::Kensho.
The goal of this change is to make Webmin more readable and hackable by anyone who knows Perl, and more fun for programmers who like Moose/Moo and other modern techniques, and to allow more modern practices in our own code. Some of these are in the standard library, and ship with Perl; others need to be installed from CPAN...but, if we pick only pure Perl implementations, we can ship them inside the Webmin distribution, and users won't need to think of dependencies any more than they currently do.
In short: If it's a complicated problem (like IO, exceptions, OO) and there's a good pure-Perl solution in the CPAN, we should consider pulling it in and replacing the web-lib functions with modern-ish OO variants. (That's not always the right answer, but, it's definitely worth looking at.)
Stage 5 (beta release ETA ??)
This one is just rolling 2.0 out to a wider user base to see how broken it is when more users are poking at it.
Stage 6 (stable release; ETA ???)
Profit!