Deprecation Model

[Laar]

As we are implementing tne functionality of OpenGL 3 we should look at what we do with the deprecation model that comes with that version.
Dagit suggested marking the deprecated functions, modules, etc. with deprecation/warning flags to notify the user at compile time.

I personally prefer some measures that are quite a bit stronger and suggest that we move the deprecated functions to its own namespace, say ...GL.OpenGL.Deprecated. This would mean quite a lot of refactoring, but the upside is that the two are much more separated from each other than they now are. Though this would include a major break in the code, so we should carefully consider this.
If we would take such action it might be a good idea to idea to restructure quite a bit more of the package as there are some more problems in my opinion.

[svenpanne]

Given the many API versions of OpenGL, I think that a deprecation model as described above is not the right way to proceed. What is considered "core" and what is considered "deprecated" is a constantly moving target. What we should do instead is mirror what OpenGLRaw already started: Combine and expose features under Graphics.Rendering.OpenGL.GL.Core43, etc. with Graphics.Rendering.OpenGL.GL being the union of all features for the lazy people (= people not caring about API versions).