Selecting compatible versions for forc and fuel-core for the default toolchains (e.g. stable, nightly, latest)
#66
Comments
|
One problem with relying on either The file metadata could instead be stored on a directory in this repo. |
In order to ensure we deliver the latest patch release, we could treat the specified E.g. if
By this do you mean storing the version sets in this repo? My concern with this approach is that we lose the main benefit of using the It's also not clear to me why it would be any easier to keep versions up to date in this repo than it would be to keep the I do empathize with the desire to keep the version selection responsibilities contained to this repo, particularly as ideally the Sway repo should not need to accommodate or even know about |
The problem about semver in the Sway repo is that |
True, I see where you're coming from. If that's the case, and we continue to treat our crate semver versions as if they are only meaningful w.r.t. breakage at the binary-user level (as we currently do for That said, I'm realising this still doesn't solve the issue we have here, which is that it's difficult to practically infer the I agree, it seems having an index of the version set for each toolchain in this repo might be the best way to go. How does the following sound:
To keep things simple to begin, we can just start with The index itself could just be some We'll also want to automate the updating of this index somehow, either using actions or some other GitHub bot. I'm not sure on the best approach here, ideally we'd do this with actions so that all the activity is publicly observable. I'm not sure what the most efficient way of triggering fuelup index updates when @binggh thoughts? Does this sound like enough to get started? |
|
Yup, all in all sounds good for a start for at least the
Rust seems to host channels on their dist server as a .toml file (eg. https://static.rust-lang.org/dist/channel-rust-nightly.toml) and I think we can probably do the same by publishing to Also, if I'm understanding this right, since we're publishing all the version sets in this repo,
Would there ever be scenarios where we release binaries while integration tests fail?
This was also where I was having difficulty trying to define, since technically we are still very early and introducing breaking updates pretty often. Maybe this is a problem for future us but setting up the infra to support
This would have to be a push-based action from |
I don't think so - if we can't guarantee that the set of versions work together, I think we're breaking the major promise of I think this is also how nightlies work for Rust too. E.g. I remember in the early days there could be up to a week or two gap in nightly releases in the case that there was some issue on
Agreed - we might even just decide that
👍 sounds decent to me! Ideally the CI in the other repos wouldn't have to know about |
Ah okay, you're talking about
Hmm, that was my first intuition as well for |
|
Going to prioritise and work on this - testing workflows within the dummy CI test repo. |
What do we think about a cron workflow here checking the latest tags through the GitHub API on the other repos? The downside here would be that depending on the interval of the checks we might not have the latest versions right away through fuelup, which seems like a non-issue to me, unless it's critical that the latest releases are ready through fuelup right away once they are released. Also I'm not aware of the CI runtime limits - would it be sane to have this cron workflow run every, say, 15 minutes? |
Hmm this does sound a bit hacky - would be greatly preferred if we can do this with a proper hook or event or something along those lines to remain immediate. I can also foresee there being occasions where app devs go to use a new release of |
|
I didn't seem to find a way to 'subscribe' to another repo's releases, hence the hacky suggestion :/ The alternative is to settle for a push-based action to update versions here then, which isn't exactly pretty as well since the other repos would now have to be aware of fuelup. You could argue that if the binary packages' main form of distribution is through fuelup then it would be fair for them to be aware of fuelup anyway, and that the impetus is on those repos to push the correct versions into a .toml file in this repo... |
|
I created 3 smaller issues and hope to use this as the tracking issue, since this issue seems to encompass the entire version set selection problem that we have to tackle across the different toolchains, each of which will probably be dealt with differently (eg. |
|
Closing this in favour of #440 to narrow the scope and for more contextual info, since 2/3 of the toolchains mentioned here are live. |
In the common case that the user hasn't specified a custom toolchain with specific versions, we need to decide on which version of
forc(and associated plugins) andfuel-coreto select.I suggest that we select the version of
fuel-corebased on the selected version offorc, asforcdepends onfuel-core, but the inverse is not true.One way of achieving this could be to select the version of
fuel-corebased on the version that was used withinforc's CI within the commit associated with the selectedforcversion. We could do this by doing something like:fuel-core-version, which just contains the semver version and nothing more.fuel-coreto fetch in the Sway CI.forc, determine the version offuel-coreto use by reading thefuel-core-versionfile.An alternative could be to select the version based on the timestamp of the commit (e.g. select the
fuel-corecommit with the first timestamp that precedes the timestamp of theforcrelease), but I think the concept of selecting commits by similar timestamps is probably much less robust than the known, CI-tested version.The text was updated successfully, but these errors were encountered: