[Mono-dev] Planning: Mono version numbers.

[Jonathan Pobst]

I think we can largely get away with keeping the major release number in 
sync with MS with what we consider *supported*, and perhaps change the 
minor number more often.

In general, the roadmap page seems pretty good, and I don't know that 
there are compelling enough reasons to abandon it.
- http://www.mono-project.com/Roadmap

2.0  (or 1.9 to denote it's almost there) - 4 months
* 2.0 support except for winforms

2.1/2.2  (or 2.0 if we call the previous one 1.9) - 9 months
* 2.0 support, including winforms

3.0 - 12-15 months?
* support for WCF, WF, and CardSpace

3.5 - 18-24 months?
* orcas support

To address some of the points about other things that muck this up:
- Gtk#: Doesn't this have its own release schedule based more on Gtk 
releases than Mono releases?
- Tools for Windows Developers: These could be added with any release, 
or not added at all, and people just go to the website and download them 
separate.
- VB compiler: Call it a preview for now.  Call it supported in 2.0.
- Mono C and D: The only one that probably necessitates a major version 
bump is the embedding API changes.  At ~9 months out, hopefully that 
could go with the 2.0 with winforms timeframe.  The others could bump it 
to 2.3, 2.4, or will probably be a runtime flag for a while anyways and 
could be enabled by default in 3.0.  (Also, embedding users *generally* 
have more control over which Mono they are using and don't just grab the 
latest from the downloads page, so the breakage may be more controlled.)
- If we define 3.0 as not having WPF, which is 2.5+ years away if we do 
it all, where do we stand on the rest? (WCF, WF, CardSpace)  It seems 
like Atsushi is making great progress on WCF/CardSpace, and there's been 
some great work on workflow as well.  That could easily fall into a 
12-15 months off timeframe.
- MS 3.5 doesn't even come out until the end of this year, assuming it 
doesn't get delayed (*wink wink*).  If we say 9 months from then, then 
18-24 seems reasonable.
- Silverlight/Moonlight isn't really a real Mono release is it?  I 
assume it will be an independent, stripped down release.  That is, if I 
wanted to run moonlight on Linux Firefox, I would download a moonlight 
plugin, not Mono 2.1/3.0/3.5/etc.  If this is the case, it does not 
affect the Mono timeline.  The security features will probably get added 
to the mainline Mono, but very few people will use them in mainline Mono 
because they won't be in mainline .Net (I assume), so they shouldn't 
affect versioning.


Of course it's not great, neither is Microsoft's.  However developers 
will have to accept Microsoft's naming.  It would really benefit us if 
we could keep ours as close as possible so developers know what to expect.

Jon