Skip to content

Commit

Permalink
WG comments
Browse files Browse the repository at this point in the history
  • Loading branch information
Perksey authored Jan 27, 2025
1 parent b754949 commit 0c7ca16
Showing 1 changed file with 5 additions and 3 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@ Proposal for maintenance reform to encourage wider applicability of Silk.NET by

# Current Status
- [x] Proposed
- [ ] Discussed with Working Group
- [ ] Approved
- [ ] Implemented
- [x] Discussed with Working Group
- [x] Approved
- [x] Implemented

# Conventions

Expand Down Expand Up @@ -120,6 +120,8 @@ Additional Bindings to retain their eligibility as Additional Bindings **shall**
4. The Bindings Owners meets the requirements for Silk.NET Community Project Maintainers as defined by the Silk.NET Community Program.
5. Both the Bindings Owners and Additional Binding **shall** be subject to any other Silk.NET Community Program requirements not listed here [6].

Where Additional Bindings are not fully classed as stable, as agreed by the Bindings Owners and the Silk.NET Maintainers, Additional Bindings packages should use a version suffix to indicate this. This should not impact other unrelated Silk.NET packages i.e. the version suffix is only applied to the Additional Bindings.

The Silk.NET maintainers **must** ensure that Additional Bindings and Bindings Owners are in compliance with these requirements on an ongoing basis and, if arrangements cannot be made to bring the Additional Binding into compliance with these requirements, the Additional Binding **must** be excluded as a Silk.NET artifact as published to NuGet. An Additional Binding that is not compliant **should** only be removed from the repository if it poses a maintenance concern for the maintainers.

Additional Bindings **may** define additional APIs that do not deviate noticeably from the API being bound to or that do not target wider applicability outside of the context of that specific Additional Binding. This could include C#-friendly wrappers for instance, provided these do not attempt to abstract the original API in any noticeable way (small utility functions are acceptable however). If compliance with this requirement is in doubt, a Bindings Owner **should** contact the Silk.NET maintainers team. Bindings Owners **may** introduce larger-scale HLUs (i.e. that abstract away the original API or target wider applicability beyond the scope of the Additional Binding), but such APIs **must** be held to the same standard of scrutiny as all other APIs approved by the Working Group and use a review process similar to the Working Group's policy. Namely, such reviews **must**:
Expand Down

0 comments on commit 0c7ca16

Please sign in to comment.