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.

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

Release schedule of spec 3.0 #880

Closed
jonaslagoni opened this issue Dec 7, 2022 · 8 comments
Closed

Release schedule of spec 3.0 #880

jonaslagoni opened this issue Dec 7, 2022 · 8 comments
Labels
:shipit: Release An issue/PR containing details about a release of the specification stale

Comments

@jonaslagoni
Copy link
Sponsor Member

jonaslagoni commented Dec 7, 2022

Up until now, we have slowly worked our way through issues and slowly progressed as time went on, but now it seems there is consensus to get "down to business".

In the last meeting, we discussed setting the release date and freeze period for when the last change to the spec can happen. This issue finalizing that proposal, and this is only a proposal and not an order 😄

Remember we do not have a targetted scope for spec 3.0, the scope is what has reached RFC stage 3 at the time of the release. Read more about the RFC process in the contributing guide.

Therefore this release schedule suggests a specific release period and a freeze period to give people an adequate amount of time to review the final version before it's released.

Release 3.0.0 is scheduled for June 2023

The suggestion is to release spec 3.0 at the end of June next year (in the second release period), and whatever proposals has reached RFC stage 3, at that time will be included in version 3.

Freeze period from February 2023

The suggestion is from the end of February no more new changes are allowed into spec 3.0, from then on it's only about finalizing what we have. That means that any proposals that have not reached RFC stage 2 (should it be stage 1?) will not be included in spec 3.0, regardless of whether they finish between February and the end of June.

What this means is that the only change that can happen from February onwards are:

  • Review and minor edits of existing changes.
  • Finalizing tooling implementations in the parser and JSON-schema-spec repository to reach stage 3 (as stage 2 does not mean the implementations are finalized).
  • Removal of existing features that are deemed rejected.
@jonaslagoni jonaslagoni added the :shipit: Release An issue/PR containing details about a release of the specification label Dec 7, 2022
@derberg
Copy link
Member

derberg commented Dec 13, 2022

For 3.0 freeze period makes a lot of sense as maintainers then can focus on checking the spec in action. I think we can say that for the February, freeze RFC Stage 2 should be required. People still have 2 months to push as champions, and we have regular meetings to speed up discussion.

I also think we should define some must-haves for the release. Release notes and schema + parser are not enough for 3.0

@jonaslagoni
Copy link
Sponsor Member Author

I also think we should define some must-haves for the release. Release notes and schema + parser are not enough for 3.0

@derberg I think that is a completely valid point, let's see who wants to chip in.

Here is the list of things I seek out to make sure is updated for v3 (either through good first issues or manually do them)

  • Generator
  • Modelina (otherwise some code templates cant update)
  • All templates (it will be somewhat of a major task to convert them, but then again I don't think it's that bad)
  • EDAVisualiser

I also think that when the spec freeze happens, we can do spec v3 office hours where maintainers can get help updating their implementation, or contributors can get help solving the update issues.

Thoughts?

Copy link
Member

derberg commented Dec 19, 2022

I like office hours idea, it will be needed also for docs contributors.

Not sure if all templates need to be migrated but for sure:

  • converter
  • studio
  • react component -> html teplmate

@fmvilas
Copy link
Member

fmvilas commented Jan 18, 2023

I'm all in with the freeze period starting on March 1st this year. Whatever is complete is in, otherwise, it's not.

@jessemenning
Copy link

I'm in favor of the March 1 freeze, but would strongly support #881 being addressed in v3

@jonaslagoni
Copy link
Sponsor Member Author

jonaslagoni commented Mar 2, 2023

After the last meeting we discussed this issue and suggest the following.

We keep the proposed deadlines but make an exception to two proposals, as they are already well underway and are breaking changes:

As we are already past the deadline for when this should take effect, you have until the next spec 3.0 meeting (March 15) to object, otherwise lazy consensus applies cc code owners @char0n @fmvilas @derberg @dalelane @smoya.

@github-actions
Copy link

github-actions bot commented Jul 1, 2023

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@github-actions github-actions bot added the stale label Jul 1, 2023
@jonaslagoni
Copy link
Sponsor Member Author

Replaced by #944

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:shipit: Release An issue/PR containing details about a release of the specification stale
Projects
None yet
Development

No branches or pull requests

4 participants