Fix Linux RISC-V download link for Beta Channel 3.2.0

[cpswan]

Page URL

https://dart.dev/get-dart/archive

Page source

src/get-dart/archive/index.md

Describe the problem

If I go to the Beta Channel and select Linux as the OS the page presents download links for each of the supported architectures.

x64, IA32, ARMv8 and ARMv7 all link to working URLs

RISC-V yields:

<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<Details>No such object: dart-archive/channels/beta/release/3.2.0/sdk/dartsdk-linux-riscv64-release.zip</Details>
</Error>

Expected fix

Ensure that RISC-V zip files are created alongside the other architectures.

Additional context

The 3.2.0-210.4.beta package from 1 Nov downloads just fine.

This may be partly due to 3.2.0 becoming stable, and RISC-V not being a supported stable architecture, and is likely to resolve itself as 3.3.0 is promoted from Dev to Beta.

Right now the versions.json in the dart-docker repo has stable and beta at parity - same version number and same SHAs:

{
    "stable": {
        "version": "3.2.0",
        "sha256": {
            "x64": "4ee368d9d359a6bd02fd0b617c31cc038373878260fd58e5575a29bfaff47773",
            "arm": "643456fb31441dec020240e983c945d5dea2aafade865fc1aadca40ce4eb661b",
            "arm64": "6051c47c73ebbfef227348635c53147cf234a4df43731c10e74b72297ff95b14"
        }
    },
    "beta": {
        "version": "3.2.0",
        "sha256": {
            "x64": "4ee368d9d359a6bd02fd0b617c31cc038373878260fd58e5575a29bfaff47773",
            "arm": "643456fb31441dec020240e983c945d5dea2aafade865fc1aadca40ce4eb661b",
            "arm64": "6051c47c73ebbfef227348635c53147cf234a4df43731c10e74b72297ff95b14"
        }
    }
}

I would like to fix this problem.

• I will try and fix this problem on dart.dev.

[parlough]

Thanks for opening an issue! I didn't consider this before.

@athomas @rmacnak-google @sortie (Feel free to redirect query) This is a rare and temporary situation when stable is released and beta is updated to match (which is useful), but I'm not sure the best way to handle it in the UI when a platform is not yet built for stable. This currently affects Windows ARM64 and Linux RV64GC.

Should we:

1. Build/upload a 3.2.0 version to put under the beta channel for the non-stable platforms? So it would be found here: /dart-archive/channels/beta/release/3.2.0/sdk/dartsdk-linux-riscv64-release.zip
   • I like this solution if it's possible, especially since there may be other consumers of the beta archives.
2. Hide the beta only platforms during the temporary time stable and beta match
   • This has the downside of them temporarily disappearing from the beta archive page
3. Surface the previous beta build for the platform
4. Something else?

[cpswan]

@parlough I've previously spoken to @mit-mit about my desire to have your option 1, though that was before this download issue reared its head. Option 1 remains my preferred approach, as it solves this issue, and facilitates multi platform Docker image manifests where the RISC-V SDK is aligned to the other stable ones.

[parlough]

Yeah that definitely makes sense to me! Thanks for the extra context.

I'll defer to those I pinged though as I'm not personally familiar with the work necessary and I imagine the fix wouldn't be relevant until 3.3.0.

[sortie]

Yeah. I see the problem. When we publish the new stable, we see it's ahead of beta, and copy it to be the latest beta as well. Unfortunately it did not contain all the experimental platforms. I wrote the publishing code and hadn't thought of this particular case.

I don't have a solution at this time. I'll have to think about it. Random early thoughts:

• Perhaps it's the "promote stable to beta if ahead of beta" logic that's the weird case that we should reconsider. I'm unclear how useful that really is, since by the time stable is released, there's usually an incoming beta coming soon too. Plus the very last beta before a stable is basically the same release, so an user isn't far behind, but can't quite rely on the stable version.

• Maybe we should reconsider the whole "only platforms are only dev/beta" concept. It's creating a bunch of problems and complexity here and there whenever platforms are missing from stables. But we also don't want people getting the wrong impression of stability and commitment when we're trying out new things that isn't ready to shine yet.

• The big problem here is that the beta/release/3.2.0/ directory is a copy of the stable/release/3.2.0/ directory. However, we would have to merge in artifacts from the previous release. We do have a bunch of release provenance data and so on, this could be a little imperfect. Hmm. I may be able to do this. It's not the cleanest solution, it does follow from a special case, but it could be fine enough, and avoids having to remove any of the other abilities we try to have.

[athomas]

The obvious solution seems to be to publish the new beta before publishing the stable? Doesn't have to be long before, just a little bit.

[sortie]

The obvious solution seems to be to publish the new beta before publishing the stable? Doesn't have to be long before, just a little bit.

Not a bad idea, although that was accidentally was done this release which got us in a bit of a bad situation IMO, and what we decided to avoid for future releases. But if it's done after the beta->stable merge, then this could work, though it's a small window and not sure it's practical.

[athomas]

The obvious solution seems to be to publish the new beta before publishing the stable? Doesn't have to be long before, just a little bit.

Not a bad idea, although that was accidentally was done this release which got us in a bit of a bad situation IMO, and what we decided to avoid for future releases. But if it's done after the beta->stable merge, then this could work, though it's a small window and not sure it's practical.

It wasn't an accident, and there's no workable proposal that avoids this and doesn't have other tradeoffs that we want to avoid.

[parlough]

Thanks for taking a look and thinking about this! Some thoughts and questions:

Perhaps it's the "promote stable to beta if ahead of beta" logic that's the weird case that we should reconsider. I'm unclear how useful that really is, since by the time stable is released, there's usually an incoming beta coming soon too. Plus the very last beta before a stable is basically the same release, so an user isn't far behind, but can't quite rely on the stable version.

I really like the aspect that beta can't be behind stable, even for a short amount of time. The main pain point comes from thinking 3.2.0 is stable and using that as your lower SDK constraint (^3.2.0), but then the project not working with beta releases and beta CI failing because it's behind the stable release. I wouldn't really want to give that up.

Maybe we should reconsider the whole "some platforms are only dev/beta" concept.

I don't have a large opinion on this, as we can explicitly state the support is experimental, but that would be hidden from tooling, so I'm not sure the potential misconceptions would be worth it.

The big problem here is that the beta/release/3.2.0/ directory is a copy of the stable/release/3.2.0/ directory.

This may not make sense, but is it possible to build a stable version for the experimental platforms, but only include it in the copied beta directories? Might be good to have that extra validation for upcoming platforms?

The obvious solution seems to be to publish the new beta before publishing the stable?

This makes sense to me as long as the gap isn't too large. What are the downsides for this solution?

[athomas]

Note that 3.3 beta 1 simply wasn't published. I didn't notice this until today and published it. It should've been published the same day 3.2.0 went out. We'd still have had this issue but only for an hour or so if it had been published when it was intended to be published.

[atsansone]

This now works at https://dart.dev/get-dart/archive and https://storage.googleapis.com/dart-archive/channels/beta/release/3.3.0-174.3.beta/sdk/dartsdk-linux-riscv64-release.zip

Closing issue.

[sortie]

Reopening -- but actually -- I just realized that all the platforms are now built on stable, so this is a non-problem. However, there still isn't a technical fix in place to prevent this from rehappening if we add new experimental platforms again, but we can do the proposed process fix to publish the next beta before the stable.