search

qgis / qgis4.0_api

Tracker for QGIS 4.0 API related issues and developer discussion
3 stars 1 forks source link

Remove V2 and NG suffixes #11

Open m-kuhn opened 8 years ago

m-kuhn commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

Agreed, +1

m-kuhn commented 6 years ago

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 commented 6 years ago

Yes please. Remove them.

On Mon., 23 Oct. 2017, 7:44 pm Matthias Kuhn, notifications@github.com 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 https://github.com/qgis/qgis3.0_api/issues/11#issuecomment-338605390, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXS3N6gYWS6WEbZU11wngupLuWlrOmzks5svF_3gaJpZM4GsYzJ .

nyalldawson commented 6 years ago

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 commented 6 years ago

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)