MAME’s latest development update is a practical, if overdue, reminder that mature open-source projects eventually have to prune old assumptions. The emulation framework is raising its floor on Windows, compiler support, and toolchain dependencies, while also signaling that its once-steady monthly cadence will become less predictable. For users still on Windows 7, the message is blunt: the project is moving on. For developers and contributors, the more interesting story is not just the platform cutoff, but the broader shift toward a cleaner, narrower, more maintainable codebase.
MAME has long lived at the intersection of hobbyist nostalgia and serious systems engineering. What began as a project to document and preserve arcade hardware has evolved into a sprawling emulation platform that reaches far beyond coin-op cabinets. Along the way, it accumulated the kind of compatibility baggage that every successful long-lived codebase eventually inherits: support for old operating systems, older standards, and obsolete build environments that stay around just long enough to become invisible until they start slowing everything down.
That context matters because the new changes are not random housekeeping. They are a sign that the project’s maintainers believe the cost of legacy support has begun to outweigh the benefit. Dropping Windows 7 support, moving to C++20, and discontinuing Qt 5 for the debugger all point in the same direction: MAME is modernizing its foundation to preserve the project’s future, even if that means inconveniencing a slice of its current audience.
The announcement also introduces a subtler but significant shift: release timing is changing. MAME is no longer promising something close to a monthly update rhythm, and the next release is now expected toward the end of May rather than in April. That sounds like an operational footnote, but in software ecosystems like MAME’s, cadence affects users, contributors, downstream packagers, and community expectations. A slower release cycle can be a sign of maturity, a need for deeper testing, or a response to rising technical complexity.
There is also an important symbolic layer here. The update follows an April Fool’s post that joked about Rust migration and AI-assisted code review, which the team later clarified was a prank. That timing may have primed readers to be skeptical of anything published near April 1, but the April 7 post is clearly intended to separate comedy from policy. In other words, this is the real roadmap, and it is telling us that MAME is entering a more selective, less forgiving phase of development.
Over time, that burden becomes structural. Supporting older versions of Windows, older compilers, and niche UNIX variants is not free. Every preserved code path has to be maintained, tested, and made compatible with new features that were never designed with obsolete environments in mind. The older the support matrix becomes, the more the project risks spending engineering effort on the past instead of the future.
This is why the move from C++17 to C++20 is more than a language-number bump. In a project like MAME, language standard changes often unlock cleaner abstractions, better library support, and fewer compatibility workarounds. They also set expectations for contributors: code that is technically portable in theory may no longer be worth carrying if it prevents the project from using modern standard library capabilities or language features.
The same logic applies to the GUI and debugger stack. Qt 5 has had a long run, but Qt 6 is now the obvious long-term target for projects that want to stay aligned with current upstream support and toolchain expectations. Choosing Qt 6 over Qt 5 is effectively a bet on continuity: fewer split paths, less shim code, and less time spent accommodating old assumptions.
The release cadence change is equally revealing. Monthly releases are attractive because they create a predictable rhythm for users and contributors alike. But as a codebase grows more complex, a rigid monthly schedule can become artificial, especially if the project would benefit from shipping when a tranche of work is genuinely ready rather than to satisfy the calendar. The new plan suggests MAME’s maintainers would rather release on quality and completeness than on a fixed date.
That support is now being removed because the cost of preserving it no longer makes sense. Modern development increasingly assumes APIs, security features, and build behaviors that simply do not map cleanly onto Windows 7. The project is not punishing users so much as acknowledging the practical reality that it can no longer remain broadly compatible without compromising the pace or quality of its work.
For users already on Windows 10 or Windows 11, the transition should be mostly invisible. They will gain access to newer builds and future fixes without worrying about whether the project is bending over backward to preserve compatibility with a shrinking base of older systems. In that sense, the cutoff improves the project’s overall coherence, even if it narrows the supported audience.
It also suggests the maintainers want to avoid the perception that every month must produce a headline-friendly update. That is often a trap for mature open-source projects. Users begin to expect routine releases as proof of momentum, and developers can feel compelled to keep the schedule even when the best move is to let work bake longer. The new stance is more deliberate and less performative.
That tension is not unique to MAME. Many open-source projects eventually confront the same choice between pace and polish. MAME’s developers appear to be leaning toward polish, which makes sense for a project whose audience values authenticity, accuracy, and reliability over novelty for its own sake.
For contributors, this is both a simplification and a challenge. Simplification, because the codebase can now assume newer language features and standard library behavior. Challenge, because anyone working with aging Linux distributions, older BSD toolchains, or antiquated cross-compilation environments may have to upgrade their toolchain before they can contribute or test.
In a preservation project, that kind of cleanup matters. Emulation layers are already complicated enough without having to support older language idioms indefinitely. By raising the floor, MAME is effectively telling contributors that it would rather have a smaller set of supported environments than carry old technical debt into the next decade.
For the average player, this may not matter much. For developers and power users who rely on MAME’s debugging capabilities, it is important because the debugger is part of the project’s “serious” identity. A modern debugger stack can make the project more approachable for contributors investigating hardware behavior, reverse-engineering systems, or validating accuracy improvements.
There is also a testing cost. Every supported framework version multiplies the number of code paths and UI assumptions the project has to verify. By dropping Qt 5, MAME narrows the matrix and gives itself a better chance of shipping a debugger that is more predictable across supported platforms.
This is not unusual for a serious codebase, but the details are important. The 32-bit x86 removal reflects a broader industry shift away from 32-bit host support, especially now that most major desktop operating systems are long since x86-64-only in practice. OpenSolaris and related System V UNIX support is similarly easy to rationalize because those environments no longer represent active desktop targets. The same goes for PowerPC optimizations, which are difficult to justify when the architecture has no meaningful desktop footprint.
That sequence is interesting because it reflects how communities now process developer communication. In the age of fast-moving social media and headline aggregation, even obvious jokes can blur into rumor if they are ambitious enough. MAME’s maintainers seem to have recognized that and followed the gag with a concrete, sober update that leaves little room for misinterpretation.
The April Fool’s context also reinforces the project’s credibility. By explicitly clarifying what was a joke and then publishing a real roadmap immediately afterward, the team signals that it understands the difference between community entertainment and engineering policy. That separation is valuable in a project where trust matters.
That is the central tension in all maintenance-heavy software. The people most attached to old environments are often the same people who most want long-term compatibility. But maintaining compatibility indefinitely can degrade the very project they depend on. MAME is choosing evolution over nostalgia, and while that may disappoint some users, it is hard to argue it is irrational.
The bigger benefit may be psychological. Users often interpret compatibility cutoffs as a sign that a project is abandoning them, when in reality the project is often trying to avoid collapse under its own maintenance weight. In this case, the trade-off seems to favor keeping MAME strong for modern systems rather than keeping it stretched thin for the oldest ones.
The opportunity is to use the newly simplified baseline to reduce friction across the codebase. Once the project no longer has to accommodate old Windows versions, older Qt bindings, and outdated compiler targets, it can spend more effort on emulation fidelity, debugger quality, and architectural cleanup.
There is also a communication risk. Slower releases can be interpreted as reduced momentum unless the project explains clearly what users gain from the new rhythm. If the team does not keep expectations aligned, people may assume the project is stalling when it is really just becoming more selective.
What happens next will likely depend on whether the maintainers can convert a smaller support matrix into visible gains. Users are usually willing to tolerate stricter requirements when the upside is obvious: better performance, fewer bugs, smoother builds, or faster progress on emulation accuracy. If MAME can pair the new baseline with tangible improvements, the change will be remembered as modernization rather than contraction.
Source: Time Extension https://www.timeextension.com/news/...m-requirements-and-the-frequency-of-releases/
MAME has long lived at the intersection of hobbyist nostalgia and serious systems engineering. What began as a project to document and preserve arcade hardware has evolved into a sprawling emulation platform that reaches far beyond coin-op cabinets. Along the way, it accumulated the kind of compatibility baggage that every successful long-lived codebase eventually inherits: support for old operating systems, older standards, and obsolete build environments that stay around just long enough to become invisible until they start slowing everything down.That context matters because the new changes are not random housekeeping. They are a sign that the project’s maintainers believe the cost of legacy support has begun to outweigh the benefit. Dropping Windows 7 support, moving to C++20, and discontinuing Qt 5 for the debugger all point in the same direction: MAME is modernizing its foundation to preserve the project’s future, even if that means inconveniencing a slice of its current audience.
The announcement also introduces a subtler but significant shift: release timing is changing. MAME is no longer promising something close to a monthly update rhythm, and the next release is now expected toward the end of May rather than in April. That sounds like an operational footnote, but in software ecosystems like MAME’s, cadence affects users, contributors, downstream packagers, and community expectations. A slower release cycle can be a sign of maturity, a need for deeper testing, or a response to rising technical complexity.
There is also an important symbolic layer here. The update follows an April Fool’s post that joked about Rust migration and AI-assisted code review, which the team later clarified was a prank. That timing may have primed readers to be skeptical of anything published near April 1, but the April 7 post is clearly intended to separate comedy from policy. In other words, this is the real roadmap, and it is telling us that MAME is entering a more selective, less forgiving phase of development.
Background
MAME’s role in computing history is unusually broad for an emulation project. For many users, it is synonymous with arcade preservation, but the framework has steadily become a general-purpose emulation and documentation engine for a wide range of legacy systems. That expansion has not just increased its technical ambition; it has also increased the burden of portability, build-system flexibility, and cross-platform support.Over time, that burden becomes structural. Supporting older versions of Windows, older compilers, and niche UNIX variants is not free. Every preserved code path has to be maintained, tested, and made compatible with new features that were never designed with obsolete environments in mind. The older the support matrix becomes, the more the project risks spending engineering effort on the past instead of the future.
This is why the move from C++17 to C++20 is more than a language-number bump. In a project like MAME, language standard changes often unlock cleaner abstractions, better library support, and fewer compatibility workarounds. They also set expectations for contributors: code that is technically portable in theory may no longer be worth carrying if it prevents the project from using modern standard library capabilities or language features.
The same logic applies to the GUI and debugger stack. Qt 5 has had a long run, but Qt 6 is now the obvious long-term target for projects that want to stay aligned with current upstream support and toolchain expectations. Choosing Qt 6 over Qt 5 is effectively a bet on continuity: fewer split paths, less shim code, and less time spent accommodating old assumptions.
The release cadence change is equally revealing. Monthly releases are attractive because they create a predictable rhythm for users and contributors alike. But as a codebase grows more complex, a rigid monthly schedule can become artificial, especially if the project would benefit from shipping when a tranche of work is genuinely ready rather than to satisfy the calendar. The new plan suggests MAME’s maintainers would rather release on quality and completeness than on a fixed date.
Why this matters now
The timing points to a project that is trying to reduce friction before the next major wave of maintenance work arrives. That makes the announcement feel preventative rather than reactive. It is easier to remove old compatibility layers before they become blockers than to do so in the middle of a larger architectural change.- Legacy operating systems create hidden maintenance tax.
- Newer language standards reduce technical debt.
- Toolchain simplification improves contributor onboarding.
- Release cadence changes can reflect quality-first priorities.
- Pruning support now can make future refactoring less painful.
The Windows 7 Cutoff
The most visible user-facing change is that Windows 10 or later will soon be required for MAME on Windows. That means Windows 7 is out, and for many users that will feel like the end of an era. Even though Windows 7 has been out of mainstream support for years, a surprising number of enthusiast projects have continued to keep it limping along for the sake of older systems or stubbornly stable retro rigs.That support is now being removed because the cost of preserving it no longer makes sense. Modern development increasingly assumes APIs, security features, and build behaviors that simply do not map cleanly onto Windows 7. The project is not punishing users so much as acknowledging the practical reality that it can no longer remain broadly compatible without compromising the pace or quality of its work.
What this means for users
For typical enthusiasts, the impact will depend on how they use MAME. If the emulator is part of a dedicated Windows 7 retro gaming machine, the update may force a choice: upgrade the OS, keep an older MAME build, or move to another platform. That is unpleasant, but it is also the standard lifecycle of preservation software when the host platform ages out.For users already on Windows 10 or Windows 11, the transition should be mostly invisible. They will gain access to newer builds and future fixes without worrying about whether the project is bending over backward to preserve compatibility with a shrinking base of older systems. In that sense, the cutoff improves the project’s overall coherence, even if it narrows the supported audience.
Enterprise and hobbyist impact
The enterprise impact is limited, because MAME is not typically deployed as a business-critical application. But the hobbyist impact is real, especially among users who have deliberately isolated older Windows installs for preservation or authenticity reasons. That audience tends to value stability, which makes platform cutoffs feel more disruptive than they might in a mainstream app.- Windows 7 support is effectively over.
- Windows 10 becomes the new practical baseline.
- Older dedicated retro-PC builds may need rethinking.
- Future compatibility work should be less constrained.
- Users on modern Windows should see little disruption.
Why the Release Cadence Is Changing
The decision to stop aiming for “nearly every month” releases may be the least flashy part of the announcement, but it may prove the most consequential. Monthly releases are easy to explain and easy to plan around, but they also create pressure to bundle work into artificial cycles. If the project has reached a stage where changes are larger, riskier, or more interdependent, a slower cadence can be a sign of health rather than slowdown.It also suggests the maintainers want to avoid the perception that every month must produce a headline-friendly update. That is often a trap for mature open-source projects. Users begin to expect routine releases as proof of momentum, and developers can feel compelled to keep the schedule even when the best move is to let work bake longer. The new stance is more deliberate and less performative.
The trade-off
A slower cadence may reduce the sense of constant churn, but it can also make each release more meaningful. Larger gaps often allow for more testing, fewer regressions, and less fragmentation in downstream package maintenance. On the other hand, users who enjoy frequent fixes and incremental improvements may see the new rhythm as a loss of transparency or momentum.That tension is not unique to MAME. Many open-source projects eventually confront the same choice between pace and polish. MAME’s developers appear to be leaning toward polish, which makes sense for a project whose audience values authenticity, accuracy, and reliability over novelty for its own sake.
What users should expect
Expect fewer release announcements, but potentially more substantive drops when they arrive. Expect more time between builds, but also more room for internal changes to land without being rushed. And expect the team to continue prioritizing architecture over optics, because that is the only sustainable path for a project with this much historical baggage.- Longer intervals may improve release quality.
- Users may need to wait for fixes.
- Downstream packagers may need to adjust.
- A slower pace can reduce regression risk.
- Release timing will likely become more flexible.
The Move to C++20
The shift from C++17 to C++20 is one of the clearest signals that the project is raising its internal technical baseline. In practical terms, that means developers will need a compiler and standard library with reasonable C++20 support, and MAME is reportedly drawing the line at GCC 11 as the oldest supported version. That is a meaningful boundary because it removes a lot of ambiguity about what counts as “modern enough” to build the project cleanly.For contributors, this is both a simplification and a challenge. Simplification, because the codebase can now assume newer language features and standard library behavior. Challenge, because anyone working with aging Linux distributions, older BSD toolchains, or antiquated cross-compilation environments may have to upgrade their toolchain before they can contribute or test.
Why C++20 matters
C++20 gives projects access to a richer language and library toolkit, but its real value in a codebase like MAME is less about flashy syntax and more about maintainability. The standard’s improvements can make code easier to express, easier to reason about, and sometimes faster to compile or debug. More importantly, it reduces the need for bespoke compatibility hacks that accumulate over time and become dangerous to remove later.In a preservation project, that kind of cleanup matters. Emulation layers are already complicated enough without having to support older language idioms indefinitely. By raising the floor, MAME is effectively telling contributors that it would rather have a smaller set of supported environments than carry old technical debt into the next decade.
Contributor implications
This change may subtly reshape who contributes. Newer toolchain requirements can lower the barrier for people using current developer setups while raising it for those on legacy machines. In practice, that often means fewer “works on my old distro” debates and more emphasis on code that matches the project’s current maintenance reality.- C++20 is now the new baseline.
- GCC 11 is the oldest supported GCC version.
- Modern clang support remains viable.
- Old toolchains will increasingly fall behind.
- The codebase should gain more modern expressive power.
Qt 6 and the Debugger Stack
The discontinuation of Qt 5 support for MAME’s Qt-based debugger is another sign that the project is pushing decisively toward current upstream dependencies. Qt is the kind of foundational library that silently shapes a great many developer workflows, so changing its major version is not just a packaging issue. It affects user interface behavior, build complexity, and the long-term health of the debugger tooling.For the average player, this may not matter much. For developers and power users who rely on MAME’s debugging capabilities, it is important because the debugger is part of the project’s “serious” identity. A modern debugger stack can make the project more approachable for contributors investigating hardware behavior, reverse-engineering systems, or validating accuracy improvements.
Why the Qt transition is logical
Qt 5 is mature, but maturity can become stagnation when upstream focus shifts. Qt 6 is where future investment is increasingly concentrated, and that makes it the sensible default for a project that wants to avoid being stranded on an older GUI foundation. Continuing dual support for two major Qt generations would be wasteful and likely brittle.There is also a testing cost. Every supported framework version multiplies the number of code paths and UI assumptions the project has to verify. By dropping Qt 5, MAME narrows the matrix and gives itself a better chance of shipping a debugger that is more predictable across supported platforms.
Practical effect on users
Most end users will never notice the change directly, but anyone building from source will. The build environment is getting more opinionated, which is often a good thing in a project that has to coordinate a wide variety of emulated systems, host operating systems, and developer workflows. Fewer supported permutations should lead to fewer subtle bugs introduced by old GUI dependencies.- Qt 5 support is being retired.
- Qt 6 becomes mandatory for the debugger.
- Build matrices should get simpler.
- Debugger maintenance should become more focused.
- Source builders must update their environments.
Removed Host Targets and Why They Matter
MAME’s update also prunes several host-target features and utilities that have become obsolete or too costly to keep. Among the removals are the 32-bit x86 recompiler back-end, support for OpenSolaris and other System V UNIX systems, specific optimizations for PowerPC host systems, the aueffectutil tool for macOS, and pre-built MSYS2 environments with bundled development tools. Each of these removals tells the same story from a different angle: the project is shedding edge cases that no longer justify their maintenance cost.This is not unusual for a serious codebase, but the details are important. The 32-bit x86 removal reflects a broader industry shift away from 32-bit host support, especially now that most major desktop operating systems are long since x86-64-only in practice. OpenSolaris and related System V UNIX support is similarly easy to rationalize because those environments no longer represent active desktop targets. The same goes for PowerPC optimizations, which are difficult to justify when the architecture has no meaningful desktop footprint.
The 32-bit x86 recompiler back-end
This is probably the most technically significant removal after the OS cutoff. Recompiler back-ends are performance-critical components, and supporting 32-bit x86 in 2026 is increasingly a burden rather than a benefit. As host systems move on, emulators must spend fewer cycles accommodating architectures that have become effectively historical.Obsolete utilities and environment packaging
The removal of aueffectutil for macOS and the bundled MSYS2 environments is less dramatic but still important. Utility tools that are no longer tied to the current audio pipeline or that duplicate package-management responsibilities are exactly the kind of maintenance clutter that accumulates quietly. Removing them is a sign of a project cleaning the attic rather than building a new wing.- 32-bit x86 host paths are being retired.
- Legacy UNIX support is disappearing.
- PowerPC-specific optimizations are being removed.
- Obsolete macOS utilities are going away.
- Bundled MSYS2 environments are no longer worth maintaining.
The April Fool’s Context
The timing of this update matters because it arrives just days after MAME’s April Fool’s post joking about a Rust migration and mandatory AI-assisted review. That prank reportedly caught enough attention that the team felt the need to clarify it was a gag, and the April 7 post is clearly intended to separate jokes from real policy. The result is a kind of corrective communication: here are the actual changes, and they are very much not a joke.That sequence is interesting because it reflects how communities now process developer communication. In the age of fast-moving social media and headline aggregation, even obvious jokes can blur into rumor if they are ambitious enough. MAME’s maintainers seem to have recognized that and followed the gag with a concrete, sober update that leaves little room for misinterpretation.
Why the prank mattered
It may have also softened the landing for the real announcement. After a joke about Rust and AI, a C++20 and Qt 6 update can seem almost mundane, even though it is structurally significant. That contrast is useful: it reminds readers that the real technical work in open-source is often less dramatic than the internet imagines, but more consequential over time.The April Fool’s context also reinforces the project’s credibility. By explicitly clarifying what was a joke and then publishing a real roadmap immediately afterward, the team signals that it understands the difference between community entertainment and engineering policy. That separation is valuable in a project where trust matters.
Communication takeaway
- The prank likely amplified attention.
- The follow-up restored clarity.
- Real changes are now distinguished from satire.
- Community trust depends on that clarity.
- The project is signaling seriousness about maintenance.
What This Means for Windows Enthusiasts
For Windows users, this update is a mixed bag. On the one hand, it is undeniably bad news if you are still clinging to Windows 7 for a dedicated retro or archival setup. On the other hand, if you are already on Windows 10 or Windows 11, the practical effect may be minimal while the long-term payoff is better stability and a cleaner support base.That is the central tension in all maintenance-heavy software. The people most attached to old environments are often the same people who most want long-term compatibility. But maintaining compatibility indefinitely can degrade the very project they depend on. MAME is choosing evolution over nostalgia, and while that may disappoint some users, it is hard to argue it is irrational.
Consumer-side impact
For consumers, the update mostly changes expectations. MAME is no longer pretending that old Windows installs are part of its long-term future, which should reduce confusion and support churn. It also means users can plan around a more realistic platform baseline instead of hoping old configurations will remain viable indefinitely.The bigger benefit may be psychological. Users often interpret compatibility cutoffs as a sign that a project is abandoning them, when in reality the project is often trying to avoid collapse under its own maintenance weight. In this case, the trade-off seems to favor keeping MAME strong for modern systems rather than keeping it stretched thin for the oldest ones.
Enterprise and power-user implications
Enterprise environments are less likely to care about MAME directly, but they may care about the pattern. When a respected open-source project drops old host support and raises language standards, it often signals where the broader ecosystem is heading. That can influence packaging, dependency policy, and the willingness of organizations to keep older toolchains around.- Legacy Windows builds lose official support.
- Modern Windows users should be fine.
- The project’s support burden should decrease.
- Power users will need to modernize toolchains.
- The overall platform story becomes cleaner.
Strengths and Opportunities
The good news is that this is a disciplined modernization, not a chaotic rewrite. MAME is pruning where pruning makes sense, and that gives the project a better chance of remaining fast-moving without becoming unmaintainable. If the team executes well, these changes could improve both developer productivity and user experience over time.The opportunity is to use the newly simplified baseline to reduce friction across the codebase. Once the project no longer has to accommodate old Windows versions, older Qt bindings, and outdated compiler targets, it can spend more effort on emulation fidelity, debugger quality, and architectural cleanup.
- Cleaner baseline for contributors and maintainers.
- Better long-term maintainability across the codebase.
- Less compatibility overhead for obsolete platforms.
- Improved debugger modernization through Qt 6.
- More room for language-level improvements with C++20.
- Potentially fewer regressions from reduced build complexity.
- A healthier release strategy if the slower cadence improves quality.
Risks and Concerns
The risks are mostly about audience friction and perception. Any time a project raises its minimum requirements, some users will experience it as exclusion rather than modernization. That can be especially painful in preservation communities, where old hardware and old operating systems are often part of the culture rather than merely the platform.There is also a communication risk. Slower releases can be interpreted as reduced momentum unless the project explains clearly what users gain from the new rhythm. If the team does not keep expectations aligned, people may assume the project is stalling when it is really just becoming more selective.
- Loss of users still on older Windows installs.
- Breakage for long-lived retro-PC setups.
- Contributor friction for legacy toolchain users.
- Potential perception of slower momentum.
- Packaging headaches for downstream distributors.
- Learning curve for developers adapting to C++20 and Qt 6.
- Risk of fragmented community expectations around release timing.
Looking Ahead
The next release, now expected near the end of May, will be the first real test of how these changes feel in practice. If it ships cleanly, the new baseline may look wise and overdue. If the transition produces surprising regressions or frustrates developers more than expected, the community may spend the next few months talking less about MAME’s engineering priorities and more about the pain of transition.What happens next will likely depend on whether the maintainers can convert a smaller support matrix into visible gains. Users are usually willing to tolerate stricter requirements when the upside is obvious: better performance, fewer bugs, smoother builds, or faster progress on emulation accuracy. If MAME can pair the new baseline with tangible improvements, the change will be remembered as modernization rather than contraction.
Things to watch
- Whether the May release lands on time and cleanly.
- How quickly downstream build scripts adapt to C++20.
- Whether Qt 6 introduces any new debugger quirks.
- How much user pushback comes from the Windows 7 cutoff.
- Whether the slower cadence produces more substantial releases.
- Whether the codebase becomes easier for new contributors to work on.
Source: Time Extension https://www.timeextension.com/news/...m-requirements-and-the-frequency-of-releases/
Similar threads
- Replies
- 0
- Views
- 60
- Replies
- 0
- Views
- 30
- Article
- Replies
- 0
- Views
- 27
- Replies
- 0
- Views
- 34
- Article
- Replies
- 0
- Views
- 40