Remove V2 and NG suffixes

[m-kuhn]

We currently have a lot of these, previous versions should be deprecated or already removed even.

I am not completely convinced that it's a good idea since expected name collisions may produce hard to find errors when updating plugins.

[nyalldawson]

I'm also not sure that removing ALL the non - v2 classes is necessarily a good idea. For example, while we now have QgsPointV2 I don't think this should replace all uses of QgsPoint. QgsPointV2 is a lot larger/more complex and I think there's still a need for a simple point with just x & y class.

QgsPoint could do with a lot of cleaning though.

While there's some easy decisions (removal of old label classes for instance), basically this would need to be considered carefully on a class by class basis.

[vmora]

I realize the need for a per-class reflexion, but renaming or merging the old class in the case of QgsPoint participate to improve readability IMO.

Concerning the name collisions in plugins, I don't see how it is causing 'harder' to find errors. @m-kuhn Are you thinking about c++ plugins or python ones ?

Overall +1 for the proposal, doing without is opening the door to v3 and ngv2 suffixes.

[pcav]

Agreed, +1

[m-kuhn]

Status quo:

get_subclasses(QgsAbstractGeometry)
<class 'qgis._core.QgsAbstractGeometry'>
<class 'qgis._core.QgsCurve'>
<class 'qgis._core.QgsCircularString'>
<class 'qgis._core.QgsCompoundCurve'>
<class 'qgis._core.QgsLineString'>
<class 'qgis._core.QgsSurface'>
<class 'qgis._core.QgsCurvePolygon'>
<class 'qgis._core.QgsPolygonV2'>
<class 'qgis._core.QgsTriangle'>
<class 'qgis._core.QgsPoint'>
<class 'qgis._core.QgsGeometryCollection'>
<class 'qgis._core.QgsMultiCurve'>
<class 'qgis._core.QgsMultiLineString'>
<class 'qgis._core.QgsMultiPointV2'>
<class 'qgis._core.QgsMultiSurface'>
<class 'qgis._core.QgsMultiPolygonV2'>

Can we make this a requirement for freeze? I really wouldn't want this inconsistency to persist during the lifetime of QGIS 3.0

[NathanW2]

Yes please. Remove them.

…

On Mon., 23 Oct. 2017, 7:44 pm Matthias Kuhn, ***@***.***> wrote: Status quo: get_subclasses(QgsAbstractGeometry) <class 'qgis._core.QgsAbstractGeometry'> <class 'qgis._core.QgsCurve'> <class 'qgis._core.QgsCircularString'> <class 'qgis._core.QgsCompoundCurve'> <class 'qgis._core.QgsLineString'> <class 'qgis._core.QgsSurface'> <class 'qgis._core.QgsCurvePolygon'> *<class 'qgis._core.QgsPolygonV2'>* <class 'qgis._core.QgsTriangle'> <class 'qgis._core.QgsPoint'> <class 'qgis._core.QgsGeometryCollection'> <class 'qgis._core.QgsMultiCurve'> <class 'qgis._core.QgsMultiLineString'> *<class 'qgis._core.QgsMultiPointV2'>* <class 'qgis._core.QgsMultiSurface'> *<class 'qgis._core.QgsMultiPolygonV2'>* Can we make this a requirement for freeze? I really wouldn't want this inconsistency to persist during the lifetime of QGIS 3.0 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXS3N6gYWS6WEbZU11wngupLuWlrOmzks5svF_3gaJpZM4GsYzJ> .

[nyalldawson]

Can we make this a requirement for freeze? I really wouldn't want this inconsistency to persist during the lifetime of QGIS 3.0

Just to clarify - I don't consider feature freeze to equal api freeze. I think final release = api freeze, no sooner.

[m-kuhn]

Ok, but can we have an API freeze date prior to the final freeze still? E.g. a change like this should not land the last day before release.

Maybe 2 weeks (during which any further API change will require a very good explanation)