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

Jump to bottom

build SDK releases from master #9252

Open
1 of 4 tasks
turadg opened this issue Apr 18, 2024 · 3 comments
Open
1 of 4 tasks

build SDK releases from master #9252

turadg opened this issue Apr 18, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@turadg
Copy link
Member

turadg commented Apr 18, 2024 •
edited
Loading

What is the Problem Being Solved?

Currently we have a branch for each release of SDK. E.g.

This approach requires painstaking cherry picking and has been the source of some confusion.

Description of the Design

Make it safe to cut releases from master. This will require at least,

Tasks
Beta Give feedback
  1. acceptance test of upgrade #8961
    0 of 1
    enhancement needs-design
    anilhelvaci
  2. add code to upgrade all upgradable vats during agoric-upgrade-12 #8219
    1 of 1
    enhancement
  4. build SDK releases from an opt-out release branch on top of master #9417
    0 of 1
    enhancement
    iomekam

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations
@turadg turadg added the enhancement New feature or request label Apr 18, 2024
@dckc dckc mentioned this issue Apr 29, 2024
Closed
14 tasks
@dckc dckc mentioned this issue May 8, 2024
Merged
mergify bot added a commit that referenced this issue May 10, 2024
@mergify
fix(types): board values (#9332)
9b5b61a 
## Description

Follow up to #8774

Fix the Board types

### Security Considerations

<!-- Does this change introduce new assumptions or dependencies that, if
violated, could introduce security vulnerabilities? How does this PR
change the boundaries between mutually-suspicious components? What new
authorities are introduced by this change, perhaps by new API calls?
-->

### Scaling Considerations

<!-- Does this change require or encourage significant increase in
consumption of CPU cycles, RAM, on-chain storage, message exchanges, or
other scarce resources? If so, can that be prevented or mitigated? -->

### Documentation Considerations

<!-- Give our docs folks some hints about what needs to be described to
downstream users.

Backwards compatibility: what happens to existing data or deployments
when this code is shipped? Do we need to instruct users to do something
to upgrade their saved data? If there is no upgrade path possible, how
bad will that be for users?

-->

### Testing Considerations

<!-- Every PR should of course come with tests of its own functionality.
What additional tests are still needed beyond those unit tests? How does
this affect CI, other test automation, or the testnet?
-->

### Upgrade Considerations

The one behavior change is to omit non-remotables from the board, but
nothing should have been doing that and if it was this error will help.

Of course that doesn't need to go out in any particular chain upgrade,
but it could to minimize divergence from master until,
- #9252
This was referenced May 15, 2024
Merged
Merged
@Chris-Hibbert
Copy link
Contributor

In Slack, @mhofman said

the prerequisite to releasing from master is roughly that all vats are upgradable and upgraded, or that the code for non upgradable vats is functionally equivalent in master

@dckc

This comment was marked as off-topic.

Sign in to view
@Chris-Hibbert
Copy link
Contributor

coreEval agoric-upgrade-16av was built from a commit on master.

@dckc dckc mentioned this issue Oct 15, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@turadg @dckc @Chris-Hibbert