Monogame: Replacing XNA Namespaces

[tomspilman]

A few years ago we discussed replacing the Microsoft.Xna. namespace with MonoGame., but we felt it was too soon as WP7 and Xbox 360 was still pretty active.

So are we getting closer? Is 2015 the year we make this move?

Can we use some sort of assembly alias as a fallback for older code?

What are issues to consider? Like how would things like binary deserialization be affected which depend on ContentTypeReader names?

[theZMan]

Seems like something that would accompany a big release to me especially since its a breaking change. Older code could then use the previous version. e.g. you release a 3.99 which is all the changes with the old namespace and then 4.0 which is the official new release.

Do we have a schedule for official 'releases' - a roadmap?

But in general I think its time as long as there's no tech issues that are insurmountable.

[tomspilman]

Seems like something that would accompany a big release

Yea... I agree.

Do we have a schedule for official 'releases' - a roadmap?

There is a "Roadmap" at the end of the README.md, but it was pretty vague and needs updates...

https://github.com/mono/MonoGame/blob/develop/README.md

That is about as official as it got.

But in general I think its time as long as there's no tech
issues that are insurmountable.

I don't think there are. However I would love to figure out a path where we can map the new namespaces to the old MS XNA ones with few changes to a codebase.

[mgarstenauer]

A few years ago we discussed replacing the Microsoft.Xna. namespace with MonoGame.

I didn't join the previous discussions. What would be the reasons/advantages of changing the namespace?

Our own engine currently works with XNA and MonoGame. We have >100 samples and a lot of documentation that references the XNA documentation on MSDN. That would be a lot of files to change. But more important: We would have no API documentation to link to.

I would suggest the following roadmap: Close all gaps (there are still a few XNA features missing), then call it "3.x stable". Then move on to a new major version with possible breaking changes.

[tomspilman]

Then move on to a new major version with possible breaking changes.

That is what I would expect. I want to be as XNA 4.x compatible as possible before making any switch.

[Chaosus]

That is what I would expect. I want to be as XNA 4.x compatible as possible before making any switch.

That will be like XNA 5.0 ? I mean next version. Im excited.

[KonajuGames]

That will be like XNA 5.0 ?

We wouldn't be able to call it as such, but perhaps spiritually it could be
considered to be something like that.
​

[mrhelmut]

I agree that a fully XNA 4.0 Refresh compliant version and that it can refer to the MSDN documentation is essential. Maybe it would be interesting to name such a version "MonoGame 4.0 Refresh", so that the numbers match the XNA compliance and helps users having a better picture of where the project is heading afterward. Then, make breaking changes in a new development branch, MonoGame 5.0.

It would be nice to have an updated/extended roadmap to the XNA 4 compliance, so that contributors know where to look at.

[danzel]

I don't see that there is necessarily any reason to change namespace. Especially while we are for the most part chasing XNA still.
If we largely diverged from XNA sure, but I don't see us doing that.

[Chaosus]

Removal of backward compatibility in MonoGame is pretty good idea - for bring something new u must remove old first. I will vote for this.

[tomspilman]

Especially while we are for the most part chasing XNA still.

I don't think we have much left to chase API wise. There are some missing packed vector types, some instancing features, and a few content pipeline features.

However functionality wise our work is never done. There are always new cases and devices where something doesn't work as expected.

If we largely diverged from XNA sure, but I don't see us doing that.

It is hard to predict how much we will change in the coming years, but I expect some changes.

There is smaller stuff like we are talking about in https://github.com/mono/MonoGame/issues/3313 where we need to replace some Guide stuff with more reasonable modern APIs. We've also been adding features in like multiple GameWindow support and a new RenderTarget3D types.

At the very least supporting threaded rendering will require some big refactors. This is stuff DX12 and Metal (https://developer.apple.com/metal/) will require for us to support advances in GPU rendering moving forward.

[harry-cpp]

Just so nobody does it, if you want to add "+1" or "-1" don't write it bellow but instead just thumbs up or down the original issue above.

[InfiniteProductions]

As no one seems to have point to the most important aspect of this potential renaming, I do it: Microsoft may, or may not, be very happy that some "third party devs" use their names and brands without authorization (if it is the case), so change of namespace's name could be good there (who knows ? US and "lawyers craziness" can lead to anything).

Apart from that, I don't mind IMHO, namespace can be anything as long as features are there (but perhaps removing MS name will also push bugs away :D)

And for the main concern about a lot's of source files to change in such cases => batch processing !
Even a little C# code can recursively load all sources of a project and rename the namespace (even a "good old" find/grep/sed/shell script can do it well)

[KonajuGames]

Microsoft may, or may not, be very happy that some "third party devs" use their names and brands without authorization (if it is the case)

Microsoft have been great supporters of the project, and have developed training resources and submitted code to the project. I wouldn't worry about that.

[tomspilman]

@dellis1972 brought up type forwarding as a possible solution:

https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx

Not sure if it does, but it is worth investigating.

[KonajuGames]

I'm not sure it will fix it either. Type forwarding is per type, so it would need an entry for every public type in MonoGame. Also, it is not supported in all runtimes.https://msdn.microsoft.com/en-us/library/ms177220(v=vs.110).aspx

[willthiswork89]

Why not put a compiler directive on the namespace declaration in the monogame libraries or is that not an option? Allow people to simply specify a compiler variable if they need legacy support

[harry-cpp]

Why not put a compiler directive on the namespace declaration in the monogame libraries or is that not an option? Allow people to simply specify a compiler variable if they need legacy support

So much work... O o

[KonajuGames]

Why not put a compiler directive on the namespace declaration in the monogame libraries or is that not an option? Allow people to simply specify a compiler variable if they need legacy support

C# compilers do not have preprocessor macro support like C++. The extent of conditional symbols in C# is if a symbol is defined or not.

[harry-cpp]

C# compilers do not have preprocessor macro support like C++. The extent of conditional symbols in C# is if a symbol is defined or not.

Still, his idea is valid, we only need to select between 2 options, Xna namespace and MG namespace.

[tomspilman]

Still, his idea is valid, we only need to select between 2 options

Bigger issue is everything else.

So we then ship both sets of namespaces in the installers for each platform? Which ones do we hook up to the templates? Which ones are used by the Pipeline tool? Do we generate two sets of docs?

I'm starting to think we may just need to make a clean break for new namespaces in the develop branch, then keep the old namespaces in a maintenance mode in another branch.

[willthiswork89]

That would work, if you need legacy namespaces then checkout the legacy branch. It allows for you to eventually phase it out. We are what? 6 years past XNA's departure or something. Right now, by keeping the XNA namespace around we are further exacerbating the issue because all new games written in monogame are the xna namespace as well. Its like a bandaid just gotta rip it off :) (Easier said than done, i know)

[Harag9]

As monogame is NOT XNA anymore and it's been years since XNA departure I think you should start branding monogame and change the namespace - Yes, we would have to change our existing solutions and recompile, but if you do it from v4 onwards that would be a good time to make the change. Go for it!

[simoneddeland]

Has there been any further internal discussions about changing the namespaces?

[KonajuGames]

There has not been any further discussion on this as we are all busy with projects. I think aiming for a 4.0 release with new namespaces is the best option so far. There are a few things to be done first, such as clearing out some of the current PRs, as this change would likely conflict with every PR that hasn't been merged at that time.

[LonghronShen]

As a developer of a game engine which is based on XNA and MonoGame, I do love XNA's spirit and I want XNA lives. Since XNA itself is somewhat small minority, the people who loves XNA should be united to keep MonoGame compatible with XNA, that makes existing XNA documents, samples and other resources still usable. In fact, there is no need to rebuild those resources again. Changing namespaces doesn't make much sense and that would make existing code broken. I do agree with that MonoGame should have a new start, but I think we should start from supporting new technologies rather than entangled in namespace.

[RUSshy]

What about two repo, MonoGame-Legacy, with namespace unchanged, and only bug-fix updates, and MonoGame with new namespace and features/breaking changes

[nkast]

A less aggressive route would be to keep the legacy APIs and move all new APIs/extensions under a new namespace. A similar change can be made to the folders and organize source files under /XNA.Framework/ and /Monogame.Framework (or something similar)

[willmotil]

Well i have been thinking about this from time to time.
When monogame 4.0 hits it should be really close to xna 4.0.
xna projects should still be easily portable at that time.
You really want to be able to say Xna4.0. == Mg4.0.

I think that is the logical expectation for a user downloading monogame 4.0 that it will be like xna 4.0.

Of course the practical requirement is only that it be easy to port over.
Though different namespaces could be a confusing start, i kind of want to see this happen.

so my thought is...

When mg 4.0 switches to 5.0 i think that would probably be the time to yank the xna namespaces !
It would also be a clear point were you start to say clearly
"This is More then xna" (even though it really is now).

So one question is...
"When is mg just like xna 4.0 when all the bugs are squashed ?"

Another...
"When is mg more then xna ?"

It's not to say monogame 4.0 has to take forever either. You have to be at 3.9 whatever until its time.
Just say were at 4.0 comfortably so now jump the version to 4.0 Make it a official download. If it takes longer and your at 4.3, when you feel its time. Then jump on to 5.0 change the namespace... why not.
Does 4.0 have to be long lived at all before switching to 5.0 ?

_Ideologically what do versions mean or do they have no meaning ? In xna they surely did._
_From 3.1 to 4.0 shawn broke renderstates and nonpremultiplied alpha that was a huge change alone._

Changing the namespaces is like saying
_"this marks some planed changes beyond just xna compatibility being the primary concern now there is more, I mean doesn't that what changing the namespaces really say. Be it speed or features or organization ect"._

I do think you should do a official version release on the download page, just before a namespace change at the least and at some point monogame should be monogame.

That was my thoughts

[lloydjatkinson]

2019, pretty weird still seeing XNA in the docs!