Maintainers Roadmap #10
Comments
|
I've picked up EDIT: I can see the versions don't line up with the other packages, but I'll leave the branch name as-is for now. |
Thanks for looking into it, tho there might be a problem now since you have pushed the package https://www.nuget.org/packages/AwesomeAssertions.Analyzers and the PacakgeID is now taken and it's not under the AA org. Upd: Nvm, just saw the ownership request. You can either pull request or I can cherry pick your changes. |
I'm going to sanity check the package against a project at work today, then I'll PR it back into the org 👍 |
|
CI for AwesomeAssertions.Analyzer seems to be fully functional now, and it appears there is no need for a specific version for v8. So, this part is ready. |
My comment regarding the documentation: #2 (reply in thread) |
|
Seems that enabling coveralls wasn't hard as I thought, and it's already working for this repo: #12 (comment) and the json one. Closing the "Code Coverage" task as for analyzer it wasn't present in the original repository. |
|
I qualified rc.3 to stable 8.0.0. There's no point in keeping it in rc since FA released it as stable with basically the same changes. Should we release 7.1.1 with the updated icon? |
|
@ScarletKuro thanks for the release. |
Can you check now if you have the privilege? Honestly, I’ve never had admin rights in the org, so I'm not sure. I created a team with the privilege to control issues, etc., and sent an invite. |
|
@ScarletKuro yes, that worked, thanks. |
|
@ScarletKuro That kind of worked. You are still the only maintainer, we others are "only" members, so we can't do any advanced configuration (e.g. I don't have access to the repository settings: |
I switched from the 'Write' role to the 'Maintain' role for the 'Collaborators' team, though I think this gives a bit too much power, IMO. I cannot customize roles or create my own, as that’s a paid feature. Also, I'm not the only one, @meenzen also has owner rights, so there’s always a backup. With the rights I just granted, though, I think it’s enough to function as an individual unit, since you can even push to protected branches and manage some repo settings. |
|
@ScarletKuro Thanks. I also don't know what do grant to whom :) Never managed anything on github. |
|
Don't worry, I'm always available for mundane tasks like changing permissions. I just don't have too much time to invest in more complex things like coding new features. |
|
SonarCloud is up for all 3 repositories. |
|
AwesomeAssertions.Json for v8 is up too |
How do we decide what features to implement? Just picking issues from FA's issue page? How to handle FA v8 fixes? Since we cannot cherry-pick those, do we plan to fix them at all? |
That's a good question, and I plan to address it in a future FAQ/README. We indeed cannot cherry-pick any further commits from FluentAssertions v8, as it would be illegal. One thing the community can do is report issues directly to AwesomeAssertions, without mentioning them in the FluentAssertions repository. The community can then address the fixes in AwesomeAssertions. Alternatively, if you find a bug report in the FluentAssertions repository that hasn't been fixed by them yet, you can submit the fix to our fork. If we happen to fix it first, and then they fix it as well with similar code, that’s the only way we can avoid possible legal concerns (otherwise, it will be hard to prove that you didn't copy). Ideally, it would be best if people avoid looking at FluentAssertions entirely, to resist the temptation to copy and paste fixes from v8. |
|
The thing is, that most who contributed to FA have (at least sort of) adopted the coding style and/or how things get done. It will be somewhat difficult to not look it like FA code, if you know what I mean. |
|
Pushed new 7.2.0 version https://www.nuget.org/packages/AwesomeAssertions/7.2.0 I made some FAQ that will got to the README, let me know what should be added, edited etc. FAQ: Q: Who are the maintainers? Q: Will the license change to a more permissive or restrictive license compared to Apache 2.0? Q: How is it possible that you released version 8 with almost identical changes if version 8 of FluentAssertions is under a commercial license? Q: What is the benefit of this project, and will it continue to evolve and be maintained? Q: Are there any plans to provide documentation like FluentAssertions? Q: Why is this package using the FluentAssertions namespace? Isn't that illegal? |
|
@ScarletKuro Shouldn't we push fixes only to v8? |
The last paragraph of the question "What is the benefit of this project, and will it continue to evolve and be maintained?" somewhat explains it. The point of this sentence is that there are both commercial and FOSS/OSS projects that might be stuck with version 7. Even if they aren't directly affected, someone might not want to deal with the licensing issue in future, especially if there's a potential for upgrading to the v8 version (accidentally, as example). In another scenario, imagine you're an FOSS project, like MudBlazor. There are cases where companies fork the project and create their own version of the library, and they use the existing testing infrastructure. This could lead to issues if they unknowingly upgrade from version 7 to 8 (or if the library was already using version 8 from the beginning, which is compatible with free open-source use). There’s no way a typical FOSS project would use FA anymore, regardless of the version, and library owners have mentioned this in the FA thread, TUnit completely removed FA to avoid any confusion to avoid future TUnit adoption which makes sense to me.. Many have switched due to this, as it’s a matter of principle. Moreover, FA can no longer be trusted. |
|
My question was more: Why do we continue releasing v7 version, if we have pushed our own version 8. There is no license issue here. And that FA keeps supporting v7 is a matter of their licensing, which, however, doesn't affect our v8. So I would've expected, that you backport the latest patch to release 8.1.0 instead of 7.2.0 |
I don't think you understand the nature of these changes. I'm not going to go through all of them since I'm on my phone. |
|
AwesomeAssertions will ship v7 as well, despite FluentAssertions v7 being under the old license:
|
Ok, thanks. Sorry for the noise. |
|
@ScarletKuro We need to de-couple this fork (aka removing the fork relationship), because now one can't fork this repo anymore when a fluentassertions fork is available. I have this situation, but want to keep the fork alive... |
Add @IT-VBFK
This can be removed, now that our documentation is up-to-date. The rest looks good. |
|
Do we need dataset https://github.com/fluentassertions/fluentassertions.datasets/ extensions? |
Im undecided on this one: |
|
I'd support leaving until someone asks for it/there's a solid reason to 👍 |
|
I've added the Renovate app which is a lot better than Dependabot IMO. Once #43 is merged we'll get automated dependency update PRs. |
I think it was, because the |
I would exclude automatic update of dotnet-sdk |
|
I guess we can close this issue as all goals were achieved |
|
Are we willing to take over several |
If we are interested in them, they are a good addition to the library, and they are not outdated, then why not? |
Roadmap
This roadmap outlines the tasks required for the repository to be fully functional.
Core Tasks
All items under the AwesomeAssertions, AwesomeAssertions.Json, AwesomeAssertions.Analyzer, and Bureaucracy sections are mandatory and must be completed.
Optional Tasks
Items under the Optional section are nice-to-have features. These are not critical for the repository to function, and they can be added later or omitted without affecting the core functionality.
AwesomeAssertions
AwesomeAssertions.Json
AwesomeAssertions.Analyzer
Bureaucracy
Optional
awesomeassertions.github.io?)The text was updated successfully, but these errors were encountered: