Replies: 3 comments 2 replies
-
|
Usually, I think the best approach for dependent projects on FA is to convince them to switch to Awesome. But since this is from @dennisdoomen, there’s a risk that people might upgrade to an FA 8.0 dependency without realizing it. So, we should create a fork. However, reaching the community that relies on this library won’t be as straightforward as targeting FA’s market, meaning we could end up with a fork that nobody uses. |
Beta Was this translation helpful? Give feedback.
-
|
This is a source-only package. It is only necessary when building AwesomeAssertions. And the fork would have the only purpose of doing fixes for our stuff. |
Beta Was this translation helpful? Give feedback.
-
|
I would try option 1 and see the reaction. I understand that this dependency is owned by FA members, which raises concerns for many, but it's still an MIT project for now. Even if FA 8.0 uses it, I don't think it can fall under a commercial license since the parent project is under MIT. Additionally, if there's a bug, everyone in the community would benefit from a fix. However, if everyone is against it, then I vote for option 3. I think maintaining our own fork and package would be too much, especially since this is a library that probably few people know about. If anyone uses it outside of FA/AA, I doubt they would know about the fork. This library is also very small—just a set of extensions and not a full-fledged dependency. It's just a source-only package, so incorporating it makes more sense to me. |
Beta Was this translation helpful? Give feedback.
-
|
Of course I will accept fixes or feature requests to Reflectify. It has nothing to do with FA 8 and might benefit FA 7 as well (which remains free) as well as my other public and private projects. |
Beta Was this translation helpful? Give feedback.
-
Currently it seems like I need a patch for Reflectify in order to fix #29
How do we want to handle that?
I tend to 2.
Beta Was this translation helpful? Give feedback.
All reactions