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

Support Jazzy Jalisco #157

Open
mkhansenbot opened this issue May 16, 2024 · 4 comments
Open

Support Jazzy Jalisco #157

mkhansenbot opened this issue May 16, 2024 · 4 comments

Comments

@mkhansenbot
Copy link

ROS 2 Jazzy will be released by the end of May. We need to discuss what we want to do, I think the options are:

  1. Ignore it for this release (2024.7.0) - release humble only
  2. Move main to be based on jazzy and release only jazzy going forward
  3. Branch humble to it's own branch, move main to jazzy and release jazzy, continuing to update / release humble when there's a new sync release, but using main (jazzy) for new development
@mkhansenbot mkhansenbot added this to the humble-2024.07.0 milestone May 16, 2024
@Bckempa
Copy link

Bckempa commented May 16, 2024

I vote option 1, we do one more humble release then target Jazzy with 2024.10.0

If I remember correctly, the original intent of the release months was to ride the stabilization train with Ubuntu in April, ROS in May, then we'd have June to test, and release in July.

Right now our verification suite is small enough we can probably make it with our current team size, but delaying until October might be valuable for future releases as the V&V burden grows. Space projects move slow enough that I don't think 5 months is unreasonable plus it gives time for more downstream software to stabilize on the new Ubuntu/ROS release.

@Bckempa
Copy link

Bckempa commented May 16, 2024

Additional thought: the cycle slip accounts for the time it might take to upstream a fix for any regression found - we should account for the goal of not owning forks for as many packages as possible.

@EzraBrooks
Copy link
Member

Agreed with all of @Bckempa's thoughts here.

@EzraBrooks
Copy link
Member

We should have switching rosdistros as an acceptance criteria for the Docker refactor work

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

No branches or pull requests

3 participants