Re: [technology-pmc] NatTable Release 1.2.0 - Request for approval

[Dirk Fauth <dirk.fauth@xxxxxxxxx>]

Hi,

thank for your thoughts. I personally would like to go with 1.2.0, but I also started a discussion on the forum the get some user thoughts on this: https://www.eclipse.org/forums/index.php/t/954528/

>> I wonder if the use case of “open framework” means technically forking NatTable

No, it means technically to customize a NatTable instance that much that you are still using 90% of the default, but be able to do fancy stuff by providing custom interface implementations you need in your environment. The interfaces in question for example rely on trees. We have two default implementions, one that simply hides the child rows on collapse, one that is using GlazedLists TreeList, which performs a list transformation internally. This is sufficient for most of our users and we therefore hide that implementation details where possible. But I also know at least one user that needs to implement lazy loading, as the data is loaded dynamically from a server. So a custom tree model was implemented to reflect that, but it is currently to special to become part of NatTable itself. And the NatTable API allows to provide a different interface implementation if he knows what he does.

My plans for the future architecture is to make the API easier to use for default cases by still allowing to customize almost everything if needed.

Greez,

Dirk

On Tue, Jan 20, 2015 at 11:56 AM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

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)

>> Most of the interfaces are mainly used internally, but NatTable is
>> treated as "open framework", so if users customized their table in
>> that detail, they will face issues. Users that simply use NatTable
>> with its configuration possibilities won't suffer.

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

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx

_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/technology-pmc