The hype of "2.0" aside, is there a guideline for what should constitute a major version number change?
It looks like we are doing something like: Major.Minor.Release 1.18 = Major: 1, Minor: 18, (alpha|beta|etc.) I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem to justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point (like when the minor version hits tripple digits)? Also, a rewrite of MediaWiki should for sure be done in Node.js :) - Trevor On Tue, Dec 6, 2011 at 5:16 PM, Ryan Kaldari <[email protected]> wrote: > I just want a MediaWiki API 2.0 :) > > Ryan Kaldari > > On 12/6/11 1:55 PM, Dan Nessett wrote: > > This is a (admittedly long and elaborate) question, not a proposal. I ask > > it in order to learn whether anyone has given it or something like it > > some thought. > > > > Has anyone thought of creating MW 2.0? I mean by this, completely > > rewriting the application in a way that may make it incompatible with MW > > 1.x.y. > > > > Pros > > ---- > > > > * Improving the application architecture > > * Utilizing more client side resources, thereby reducing the server side > > resource requirements. > > * Clean up and improve existing services. > > > > Cons > > ---- > > > > * Rewrites of major applications normally fail because they become overly > > ambitious. > > > > Some possible ways MW 2.0 might improve MW 1.x.y > > > > Change the parser > > ----------------- > > > > * Get rid of mediawiki markup and move to html with embedded macros that > > are processed client side. > > * Move extension processing client side. > > * Replace templates with a cleaner macro-based language (but, KISS). > > > > Pros > > ---- > > > > * Reduce server side resource requirements, thereby reducing server side > > costs. Server side becomes mostly database manipulation. > > * Make use of the far larger aggregate resources available on client side > > (many more client machines than server machines). > > * With macro processing client side, debates about enhancements to parser > > extensions that require more processing shift to looking at client side. > > * Allows development of a parser driven by well-defined grammar. > > > > Cons > > ---- > > > > * Unclear whether it is possible to move all or most parser processing to > > client side. > > * Would need a (probably large and complex) transition application that > > translates mediawiki markup into new grammar. > > * Since not all clients may have the resources to expand macros and do > > other client side processing in a timely manner, may need to provide > > server side surrogate processing based on either user selectable (e.g., > > preferences) choice or automatic discovery. > > * Need to select client side processing engine (e.g., Javascript, Java), > > which may lead to major developer fighting. > > > > Clean up security architecture > > ------------------------------ > > > > * Support per page permissions, ala' Unix file system model. > > * Integrate authentication with emerging global services (e.g., OpenID) > > without use of extensions. > > * Move group membership definition out of LocalSettings into database > > table. > > > > Pros > > ---- > > > > * Chance to think through security requirements and craft clean solution. > > * Offload most authentication processing and login data protection to > > service providers that more sharply focus on its requirements. > > * Some customers have expressed interest in per page permissions. > > > > Cons > > ---- > > > > * Changing security architectures is a notoriously difficult objective. > > Most attempts lead to bloated solutions that never work in practice. > > * Some developers oppose per page permissions. > > * Would need to develop WMF standards that authentication providers must > > meet before accepting them for WMF project login. > > > > This is sufficient to illustrate the direction of my curiosity, but there > > are other things that MW 2.0 could do that might be discussed, such as: > > > > * Change the page history model. When page is flagged stable, subsequent > > page changes occur to new draft page. Provide link to draft page on > > stable page. > > * Think through how to support multiple db backends so application > > development doesn't continually break this support. > > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
