Skip to content
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.

Sign up for GitHub

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

doc: add rc version guideline #468

Closed
wants to merge 1 commit into from
Closed

doc: add rc version guideline #468

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 9 additions & 38 deletions ROADMAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,44 +6,15 @@ AsyncAPI is a specification for defining message-driven APIs. We're on a mission
## How to Get Involved?
AsyncAPI is an open-source community-driven project. We're happy to receive contributions from different people, no matter your skills or your area of expertise. There are many ways you can contribute to the project, not just code. There is always a need for: documentation, design, writing, evangelizing, code, issue triage, and more! We also welcome financial support and donations. Check out the [contributing guidelines](./CONTRIBUTING.md) to learn more.

## Timeline
## Versioning
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have to explain versioning on a Roadmap document. Also, versioning is already explained on the spec: https://github.com/asyncapi/asyncapi/blob/master/versions/2.0.0/asyncapi.md#asyncapi-version-string.

And there's a link to the latest spec in the readme already: https://github.com/asyncapi/asyncapi/#the-specification.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. 👍

AsyncAPI schema is versioned according to [semver](https://semver.org/) guidelines. You can check latest [v2.0.0 here](https://asyncapi.io/docs/specifications/2.0.0).

We're working hard to reach version 2.0.0, which will be full of great new features (and bug fixes.)
### Release Candidates (RC)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd not talk directly about RCs here. Maybe we should call them "prereleases" (as defined by Semver). We may also opt for -alphaN suffixes before we call them a "release candidate". RC should only be those versions we believe are done and therefore we want people to try and tell us if they're really done or not.

Also, not sure this is the right document for this information. Maybe we should have a separate VERSIONING.md document?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having separate RC and Alpha releases will just make it more confusing. To make it clear, RC doesn't guarantee anything. It's a candidate version for the upcoming release.

I would suggest we only follow one convention for now and not make it too complex atm. If in the future, we need to separate out we can.

I like the idea of explaining everything about RC in VERSIONING.md. Couldn't find the best place for it. Will create it now. 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some cases, we may find it useful to flag a spec version as alpha because we want to release different packages with the same version to see how everything fits together. We'll most probably do it to try things out separately, knowing it's far from being close to stable. Alpha is just another step in the software development cycle where you're experimenting, let's use it. A release candidate is a version that could potentially become the final version: https://en.wikipedia.org/wiki/Software_release_life_cycle.

For instance, I may want to release 2.1.0-alpha1 which only contains your MessageId proposal, so the team can start working on the tooling to support it. 2.1.0-alpha2 might contain a second feature we want to include, and so on. In these cases, we don't to communicate the users that we have a release candidate because we know it's far from being it. But that's ok, just because we release them it doesn't mean we have to communicate about them.

- Release Candidate (RC) version is published for MINOR and MAJOR version, so that users can validate, tests and give feedback for upcoming changes.
- RC version follow naming convention as `2.1.0-rc1`, `2.1.0-rc2` ... and so on.
- Any added functionality in RC version may change or be completely removed in the respective MINOR or MAJOR version.
- There are no release candidates (RC) for PATCH versions.

> *If you're looking for dates, check out our [Milestones](https://github.com/asyncapi/asyncapi/milestones?direction=asc&sort=due_date) page.*
### Upcoming tasks

### Finished milestones

:arrow_right: [[v2.0.0] Normalize topics and support multiple schemas](https://github.com/asyncapi/asyncapi/milestone/3)

Before we continue heading to version 2.0.0, let's make the biggest breaking changes in the history of AsyncAPI: topic normalization and support for multiple schemas.

:arrow_right: [[v2.0.0] Improving connectivity](https://github.com/asyncapi/asyncapi/milestone/1)

This milestone tackles the issues related to connecting to a server. These issues are very important to resolve for SDKs and code generators to work properly.

:arrow_right: [[v2.0.0] Improve user experience](https://github.com/asyncapi/asyncapi/milestone/4)

This milestone is about improving developer/user experience for the specification and the tooling.

:arrow_right: [[v2.0.0] Protocol mappings](https://github.com/asyncapi/asyncapi/milestone/2)

This milestone is about figuring out how to map protocols to AsyncAPI documents.

:arrow_right: [[v2.0.0] Augmentation](https://github.com/asyncapi/asyncapi/milestone/5) :white_check_mark: Current milestone

This milestone is about creating mechanisms for the users to augment the AsyncAPI specification. We already have specification extensions, which provide a syntactical way to extend the spec. In this milestone, we should aim for providing the right mechanisms to extend the spec in different contexts and ways.

:arrow_right: AsyncAPI version 2.0.0 Release Candidate launch

There's a new AsyncAPI version and now it's time for the tooling vendors to finish implementing it.

:arrow_right: :tada::tada::tada: AsyncAPI version 2.0.0 launch

Official launch of AsyncAPI 2.0.0! Party hard! :beers:

### Next milestones

:arrow_right: [Backlog](https://github.com/asyncapi/asyncapi/projects/4)

The purpose of the backlog is to temporarily group issues that may be considered for the future. Please, note that it doesn't mean they will get implemented, however, there is a big chance.
You can check upcoming features and in-progress tasks thorugh [ZenHub Dashboard](https://app.zenhub.com/workspaces/asyncapi-initiative-5e541969da30b0bc34628b22/roadmap)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for removing the junk here. Let's not point to Zenhub as you either need an account or the extension to see the information. Let's use shapeup.asyncapi.io instead. Actually, this whole document should probably be removed and we just add links to README pointing to shapeup.asyncapi.io.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. 👍