Comment From: snicoll
Looking at the number of changes, I've changed my mind. It would be better to do this after the restructure work. There are a number of commits that already have removed deprecated code as part of the refactoring.
Comment From: snicoll
@wilkinsona looking at the commit, I can see that deprecated configuration properties have been removed without updating the additional metadata to indicate they are now with error level. I don't remember if we have a tool to generate that though and you plan to add this later.
When I was trying it out, I was copying the generated metadata before removing the code and pasting it in additional with the change in deprecation level.
Comment From: wilkinsona
Do we need that error-level metadata? We need to draw the line somewhere and a major revision feels like a good place to do it. Perhaps it's useful so that users are alerted to the fact that a property won't do anything. If we want to keep it, I'd like to have a plan in place for removing it at some point.
Comment From: snicoll
I think we need that yes. I am a bit surprised you're asking the question given it's a feature of the metadata after all: it warns users about properties they might be still using that are gone. The properties migrator also relies on this information.
I can understand that we'd like to get rid of those at some point but there's little maintenance cost associated with them as all they say is "this property no longer exists", which is different from "we don't know what this is". We don't need need to look at them or upgrade them if something in the code changes.