API breakage in return type of LinkTracking()

[sminnee]

First raised in silverstripe/recipe-cms#12 and discussed during its introduction at #75 (comment)

LinkTracking() now returns SiteTreeLink objects when it used to return SiteTree objects.

It should be corrected to return SiteTree objects, and if necessary a new method can be created to return SiteTreeLink.

Otherwise it's an API breakage.

We should fix this before 4.2 is made stable so that people don't inadvertently start correcting their code to the new API.

Marking as critical as it's a release blocker.

[sminnee]

Please note that marketing versioned as 2.0 would really imply that the recipe is 5.0, which is unacceptable in terms of getting people actually using our updated code. Unlike the GraphQL module we can't make the argument that versioned is an "experimental" API.

[tractorcow]

Back from China and able to properly look at this.

LinkTracking() now returns SiteTreeLink objects when it used to return SiteTree objects.

Actually the change is that it used to return a ManyManyList but now returns a ManyManyThroughList, which is another sibling class. Both extend RelationList base.

Both lists dataClass() are SiteTree, and has not been changed to SiteTreeLink.

[tractorcow]

See my comments at silverstripe/recipe-cms#12 (comment) also.

[tractorcow]

@sminnee I'm changing my mind about this. Can you please read my updates (here and on the cms recipe ticket) and let me know if you agree. I don't think this is a real bug.

[sminnee]

Hopefully we can get some confirmation about the other bug. Seems reasonable, thouhg.

Perhaps we should update the docblock on LinkTracking to clarity what return type we are committing to (RelationList?). Is it reasonable to expect callers to only rely on facilities exposed by RelationList?

[chillu]

Related phpstan issue has been closed (https://github.com/silbinarywolf/silverstripe-phpstan/issues/13), according to Damian this isn't a bug. Closing.