Rename EdcSetting to Setting

[paullatzelsperger]

Feature Request

If you are missing a feature or have an idea how to improve this project that should first be discussed, please feel free to open up a discussion.

Type of Issue

improvement

Checklist

• assigned appropriate label?
• Do NOT select a milestone or an assignee!

[ndr-brt]

To make the transition softer we could introduce a new Setting annotation and deprecate EdcSetting for some time

[paullatzelsperger]

To make the transition softer we could introduce a new Setting annotation and deprecate EdcSetting for some time

Here, deprecating seems like an awful lot of ceremony for a simple seach-and-replace job, because it is not as simple as just putting @Deprecated there: we'd also have to touch the annotation processor and the runtime metamodel, and then change it back later.

[paullatzelsperger]

@ndr-brt I thought about it again and as it turns out, it may indeed make sense to deprecate it first, because otherwise all EDC builds would fail...
However, we should remove the @EdcSetting as soon as a corresponding refactoring PR in EDC is merged.

[ndr-brt]

@ndr-brt I thought about it again and as it turns out, it may indeed make sense to deprecate it first, because otherwise all EDC builds would fail... However, we should remove the @EdcSetting as soon as a corresponding refactoring PR in EDC is merged.

Could we do that after Milestone 7 release? that would give some time to the downstream project to adapt, I think this is a good practice we should adopt

[paullatzelsperger]

Could we do that after Milestone 7 release? that would give some time to the downstream project to adapt, I think this is a good practice we should adopt

We always said we do not guarantee stable APIs until version 1.0.0 and that breaking changes (API, SPI, etc.) are to be expected until such time. I do not want to get caught up in a situation where (in a pre-release version!) we need to keep track of what is deprecated, what is scheduled for removal etc. Here, the adoption should be trivial, because it's just a search-and-replace across the code base, since package declarations do not change.

[ndr-brt]

Could we do that after Milestone 7 release? that would give some time to the downstream project to adapt, I think this is a good practice we should adopt

We always said we do not guarantee stable APIs until version 1.0.0 and that breaking changes (API, SPI, etc.) are to be expected until such time. I do not want to get caught up in a situation where (in a pre-release version!) we need to keep track of what is deprecated, what is scheduled for removal etc. Here, the adoption should be trivial, because it's just a search-and-replace across the code base, since package declarations do not change.

This will cost nothing to us and it will be an huge help for the community, we just need to wait 2 weeks to do it