| Re: [technology-pmc] NatTable Release 1.2.0 - Request for approval |
| Hi Dirk, Thanks for taking the time to discuss the API issues raised. I think the main question is, which API principles were defined in the beginning. It looks like no thought was put into this when producing the current releases. In this case, it’s up to project to continue with the mess. Of course, we encourage projects to adopt a good policy but we can’t enforce it. It’s really up to the project to discuss and pros and cons and decide about any community disruptions. I see two options: 1) Go with 2.0. 2) Continue with 1.2.0. I think the implications for 1) are: - export bundle and packages as version 2.0 - communicate that the architecture change is deferred to 3.0 - revise the package exports with regards to user, service provider and internal API in 3.0 For 2) I see: - export bundle and packages as version 1.2 (you are already doing this) - communicate breaking api changes (you are already doing this) - label interface that should never be implemented by users as @noimpliment (note, this still means they could be implemented by service providers) - communicate that implementing those interfaces was never considered an option for regular users - you could also consider declaring some packages as internal now (which should have been from the beginning)
There is still room for breaking api changes in a minor release for service providers. Service providers can be adopters providing a different implementation of specific classes. I’m not sure if that applies to the interfaces in question and if this applies to the “open framework” part. However, I wonder if the use case of “open framework” means technically forking NatTable. In any case, you could also just post to your users channels and see if there are any concerns. Anyway, from a PMC perspective, I’m fine with going forward with option 2). I believe it’s a good idea to clean up a mess and your release material is already pretty good at communicating that. +1 |