New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacing XNA Namespaces #3306

Open
tomspilman opened this Issue Dec 23, 2014 · 28 comments

Comments

Projects
None yet
@tomspilman
Member

tomspilman commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@theZMan

theZMan Dec 23, 2014

Contributor

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.

Contributor

theZMan commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Dec 23, 2014

Member

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.

Member

tomspilman commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mgarstenauer

mgarstenauer Dec 23, 2014

Contributor

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.

Contributor

mgarstenauer commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Dec 23, 2014

Member

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.

Member

tomspilman commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Chaosus

Chaosus Dec 23, 2014

Contributor

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.

Contributor

Chaosus commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Dec 23, 2014

Contributor

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.

Contributor

KonajuGames commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mrhelmut

mrhelmut Dec 29, 2014

Contributor

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.

Contributor

mrhelmut commented Dec 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@danzel

danzel Dec 30, 2014

Contributor

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.

Contributor

danzel commented Dec 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Chaosus

Chaosus Dec 30, 2014

Contributor

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

Contributor

Chaosus commented Dec 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Dec 30, 2014

Member

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 #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.

Member

tomspilman commented Dec 30, 2014

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 #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.

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy Apr 8, 2016

Member

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.

Member

cra0zy commented Apr 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@InfiniteProductions

InfiniteProductions Apr 13, 2016

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)

InfiniteProductions commented Apr 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Apr 13, 2016

Contributor

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.

Contributor

KonajuGames commented Apr 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Apr 13, 2016

Member

@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.

Member

tomspilman commented Apr 13, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Apr 13, 2016

Contributor

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

Contributor

KonajuGames commented Apr 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@willthiswork89

willthiswork89 May 23, 2016

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

willthiswork89 commented May 23, 2016

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

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 23, 2016

Member

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

Member

cra0zy commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames May 23, 2016

Contributor

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.

Contributor

KonajuGames commented May 23, 2016

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.

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 23, 2016

Member

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.

Member

cra0zy commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman May 23, 2016

Member

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.

Member

tomspilman commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@willthiswork89

willthiswork89 May 23, 2016

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)

willthiswork89 commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Harag9

Harag9 Jul 7, 2016

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!

Harag9 commented Jul 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@simoneddeland

simoneddeland Sep 2, 2016

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

simoneddeland commented Sep 2, 2016

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

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Sep 4, 2016

Contributor

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.

Contributor

KonajuGames commented Sep 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@LonghronShen

LonghronShen Oct 31, 2016

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.

LonghronShen commented Oct 31, 2016

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

This comment has been minimized.

Show comment
Hide comment
@RUSshy

RUSshy Feb 23, 2017

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

RUSshy commented Feb 23, 2017

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

@nkast

This comment has been minimized.

Show comment
Hide comment
@nkast

nkast Feb 24, 2017

Contributor

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)

Contributor

nkast commented Feb 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@willmotil

willmotil Feb 24, 2017

Contributor

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

Contributor

willmotil commented Feb 24, 2017

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

@tomspilman tomspilman modified the milestones: 4.0 Release, 5.0 Mar 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment