-
-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Road to v2.0.0 #481
Comments
@magicmatatjahu would you mind adding #482 into the list? |
@smoya Added :) |
@magicmatatjahu as #294 is not really a BC, we can remove it from the list so we move forward just with the minimum. |
@magicmatatjahu as #405 is not really a BC, we can remove it from the list so we move forward just with the minimum. |
@magicmatatjahu as #404 is not really a BC, we can remove it from the list so we move forward just with the minimum. |
@magicmatatjahu I'm concerned about #403 as this would become a BC, so perfect for the new parser version, but it requires a lot of effort. Do you think we should invest on this for the next version of the Parser? cc @jonaslagoni @fmvilas |
@magicmatatjahu can you annotate #201 is done? |
@magicmatatjahu as #157 is not really a BC, we can remove it from the list so we move forward just with the minimum. |
We could build another list, instead of removing issues, with the Nice To Have issues. In case there is time or people willing to take those. EDIT: Here is the list @magicmatatjahu . You can add it right after the current list on the description of this issue. Nice To Have
|
@magicmatatjahu This is going to be needed as well asyncapi/parser-api#69 |
After giving another thought to the list of tasks for v2.0.0 of the parser, I think we can go further and reduce the scope. I considered AsyncAPI Roadmap at all moments to see how we could deliver value asap (the new API). Here is what I would suggest we could move with, but I know @magicmatatjahu had strong reasons not to discard some of the tasks, so I'm going to ask you if you could expand info on why you believe those are needed. I'm addressing to you since you created most of those issues, also because you have a good knowledge of the v1.x code base, however, anyone is invited and encouraged to jump into this discussion so we can find the minimum required features for the new version.
|
Tbh, the only thing I see as required would be #482 (because that's already underway) and #401 (because well, that is what triggers this rewrite). My reason for only those two is that is what is directly needed from the generator's perspective and probably where #401 is needed the most. That said, remember... You can do another major release in another month if that's what you would like to do where you address even more of these issues. Nobody is stopping you from releasing new major versions of the parser. |
I already explained you. For me it would be too much pointless work, because from the beginning there was a thought to use Spectral and for that we have collaborations with Spotlight team regarding the official ruleset AsyncAPI. However if community thinks that it's better idea (it's usually right, isn't?) we can do this, but we should discuss that. cc @derberg @jonaslagoni @fmvilas
If we do not go with Spectral then it is not needed, but the function
For this we have in mentorship program that project https://github.com/imabp/asyncapi_problem but with Spectral we won't need that in 99% cases. As I think there, even in the case of using logic from our parser, it should not be necessary. I would throw this issue from the scope and even close it. |
Yeah, but we talked privately so I wanted to add visibility to this, opening the discussion to whoever is interested in this whole community.
I understand moving to Spotlight is something we must eventually do. The fact we unify validation logic into just one place, the way Spectral does validation based on rules, etc, is way better to what we have right now in current parser. On that side, I agree @jonaslagoni on the following statement:
Having said that, I would love to know what is the status of the development of AsyncAPI rules on Spectral. Is there any rule that the current parser has but Spectral doesn't? Maybe there is an issue tracking the progress that I'm missing (sorry if that's the case). I'm asking that because if we are done in Spectral side, maybe we could evaluate moving forward with only the following in addition to what I mentioned: Thoughts? Ideas? |
@magicmatatjahu could u please add #620 to the list of TODO? |
Also this one @magicmatatjahu asyncapi/parser-api#69 |
@smoya Done. |
What's really stopping us from releasing Parser v2? I want to move this forward as soon as possible so we can start receiving feedback. |
There is missing work that should go in Spec v3.0.0 that still is not supported in the Parser. Champions are willing to work on it. See asyncapi/spec#691 (comment) Some kind of summary:
|
This issue contains list of possible features that we wanna introduce in the
v2.0.0
of ParserJS. Have in mind that some of them may not be implemented. You can also write your own proposals/features/PRs in the comments, I will update then the main list.stringify
function available on the instance of AsyncAPIDocument class #421Nice To Have
$ref
links #360 - we need to check that in v2 by simple testscc @jonaslagoni @smoya
The text was updated successfully, but these errors were encountered: