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

Work on 2.4.1 release #821

Closed
3 of 7 tasks
smoya opened this issue Jul 13, 2022 · 9 comments
Closed
3 of 7 tasks

Work on 2.4.1 release #821

smoya opened this issue Jul 13, 2022 · 9 comments
Labels
:shipit: Release An issue/PR containing details about a release of the specification

Comments

@smoya
Copy link
Member

smoya commented Jul 13, 2022

Release 2.4.1 is scheduled for July 2022

Detailed info:

Potential work to be included in this version

Accepted

Progress:

- [ ] Create release branches
- [ ] Update release branches with new versions
- [ ] Update default branches with release branch name
- [ ] Create draft release notes
- [ ] Update release branches from forks
- [ ] Notify community about release branches

  • Check for potential release contributions

- [ ] Draft announcement blog post for new features and changes
- [ ] Write release notes for new features and changes
- [ ] Prepare pull requests to merge release branches into master
- [ ] Notify tsc_members about upcoming release

  • Merge release branches into master
    • spec

- [ ] Write release notes for the releases on Github

  • Create releases on Github
    • spec
  • Update RELEASE_PROCESS doc with any changes

Cleanup tasks after the release

  • [ ]
@smoya smoya added the :shipit: Release An issue/PR containing details about a release of the specification label Jul 13, 2022
@smoya
Copy link
Member Author

smoya commented Jul 13, 2022

Please correct me if I'm wrong @derberg, this is our first minor version release. Meaning we should make some decisions on how we want to approach this.

In order to release, technically all we need to is to merge #776. This will trigger 2.4.1 version.
However, that's not all. There are some other tasks, based on RELEASE_PROCESS.md, we would need to decide if we do all of them, some of them, or none.

IMHO, we could do all of the above.

What are your thoughts? cc @dalelane @derberg @fmvilas

@dalelane
Copy link
Collaborator

In theory, I think it's reasonable to do a subset to try and keep patch versions as cheap as possible. But in practice, other than the blog post, I don't think there is much that we can really skip.

@derberg
Copy link
Member

derberg commented Jul 14, 2022

looking at the list, I would ask is it worth the effort if we have 2.5 scheduled for September, so 1.5 month away

@smoya
Copy link
Member Author

smoya commented Jul 14, 2022

looking at the list, I would ask is it worth the effort if we have 2.5 scheduled for September, so 1.5 month away

For me, it is worth it if we end up defining the process for patch releases. It is something we could have at some point anyway (a more urgent fix might be needed eventually, for example).

@fmvilas
Copy link
Member

fmvilas commented Jul 18, 2022

I think it's very unlikely we'll have an urgent patch release to do in the future. The spec shouldn't have such urgency IMHO. Dunno, not worth the effort for me.

@smoya
Copy link
Member Author

smoya commented Jul 19, 2022

I think it's very unlikely we'll have an urgent patch release to do in the future. The spec shouldn't have such urgency IMHO. Dunno, not worth the effort for me.

Fair enough, TBH. A couple of things:

  1. SemVer says the following for PATCH releases:

    PATCH version when you make backwards compatible bug fixes.
    [...]
    Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

    As far as I can see, critical changes that could be worth to release ASAP won't go into the PATCH but MINOR or MAJOR. So 👍 .

  2. Would it make sense to mention somewhere (Maybe the RELEASE_PROCESS.md) AsyncAPI won't ever release PATCH versions?

  3. Consider moving to <major>.<minor> versioning, like OpenAPI does.

cc @dalelane @derberg @fmvilas

@derberg
Copy link
Member

derberg commented Jul 25, 2022

AsyncAPI won't ever release PATCH versions?

I'm personally always afraid of such statements, I like saying never say never

the fix that we now say to do in a MINOR would normally by a PATCH. But because we are short from MINOR and other important things to do, we just say yeah, no need to really do anything here, especially because of holidays dead season, and we can easily just release the fix with other features in September

what I'm trying to say, this is still a PATCH but I don't see we are obligated to release it if it is not really critical and needed

@char0n
Copy link
Collaborator

char0n commented Sep 9, 2022

Do I correctly assume that 2.4.1 release effort was discontinued? Given we already have 2.5.0 effort on the way.

@smoya
Copy link
Member Author

smoya commented Sep 12, 2022

@char0n your assumption is correct. Closing in favour of #830.

@smoya smoya closed this as completed Sep 12, 2022
@smoya smoya closed this as not planned Won't fix, can't repro, duplicate, stale Sep 12, 2022
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
Projects
None yet
Development

No branches or pull requests

5 participants