-
-
Notifications
You must be signed in to change notification settings - Fork 285
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
Define and document process for release candidates (RC) versions of schema #463
Comments
Great initiative! Would be happy to help and experimenting the RC release process. What would be your first ideas or suggestions? On the OpenAPI Spec side, they seem to work on specific repo branch for WIP and produce different markdown files for keeping the different releases always at hand in the Is the labelling all the candidate issues up-to-date or a new triage has to be done? |
@lbroudoux Thanks. But yeah. We need to first define RC process and document it. I don't think we have labels for all the candidate issues, but I think once we have a process defined, people will automatically start following it. |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
Entire release process, including part about release candidates is already documented here https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md |
Currently, we have a lot of feature requests piling up for 2.1.0 (https://github.com/asyncapi/asyncapi/issues/353 zenhub) but there is no clear feedback from the community.
As discussed in SIG meeting #462
We need to define/document RC versions for the schema. This is so that tooling, external packages, users can start using upcoming features early. This way, users can give feedback and make suggestions on the RC version and feedback can be incorporated in the next minor or major release accordingly.
RC would be done only for minor and major versions. patch versions should be rolled out without RC.
Next steps
The text was updated successfully, but these errors were encountered: