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 v0.7.0 requirements #683

Closed
3 of 9 tasks
danielvegamyhre opened this issue Oct 5, 2024 · 13 comments
Closed
3 of 9 tasks

Release v0.7.0 requirements #683

danielvegamyhre opened this issue Oct 5, 2024 · 13 comments

Comments

@danielvegamyhre danielvegamyhre added the kind/bug Categorizes issue or PR as related to a bug. label Oct 5, 2024
@ahg-g
Copy link
Contributor

ahg-g commented Oct 5, 2024

Another must have: #682

@danielvegamyhre
Copy link
Contributor Author

Another must have: #682

Sounds good, added.

@danielvegamyhre danielvegamyhre pinned this issue Oct 5, 2024
@danielvegamyhre danielvegamyhre removed the kind/bug Categorizes issue or PR as related to a bug. label Oct 5, 2024
@kannon92
Copy link
Contributor

I really think #463 could be ready for this release.

@danielvegamyhre
Copy link
Contributor Author

I really think #463 could be ready for this release.

Agreed - added it.

@kannon92
Copy link
Contributor

I think we should remove #463 and #482.

We should consider elasticity as a general KEP and maybe these two issues can be considered.

@danielvegamyhre
Copy link
Contributor Author

I think we should remove #463 and #482.

We should consider elasticity as a general KEP and maybe these two issues can be considered.

Removed #463 (see my comment here regarding a KEP for elasticity). However, #482 isn't related to supporting use cases requiring elasticity, it's just changing an implementation detail for an existing API (exclusive job placement per topology domain) to improve efficiency, so I've left it in.

@danielvegamyhre
Copy link
Contributor Author

Added #684 to goals for 0.7.0, cc @nstogner

@ahg-g
Copy link
Contributor

ahg-g commented Oct 24, 2024

I would like to move ahead with the release without #672 so that #672 can take its time in discussions. Any objections?

@danielvegamyhre
Copy link
Contributor Author

I would like to move ahead with the release without #672 so that #672 can take its time in discussions. Any objections?

Yeah I agree, there are some fundamental design decisions that are still being heavily discussed. If we need to do a release to ship other features (e.g., RestartStrategy) to users soon, then we can aim to include #672 in the next release instead. I'll go ahead and remove it.

@ahg-g
Copy link
Contributor

ahg-g commented Oct 24, 2024

Are you able to actually do the release? :)

@danielvegamyhre
Copy link
Contributor Author

Are you able to actually do the release? :)

I can probably do it this weekend. Has anyone manually tested the changes #682 (preemption) and #684 (blocking restarts)?

@ahg-g
Copy link
Contributor

ahg-g commented Oct 25, 2024

Yes, we tested both.

@danielvegamyhre
Copy link
Contributor Author

Release 0.7 published

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants