opencode: Add version 1.1.15

[scillidan]

This is only CLI version.

The Desktop version will be in Extra bucket.

Closes #7237

• Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
• I have read the Contributing Guide

[github-actions]

All changes look good.

Wait for review from human collaborators.

opencode

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate

Check the full log for details.

[itsrainingmani]

yoooo thanks for adding this! I was just about to make a PR

[Lutra-Fs]

We agree that it should be happened, but currently we are lacking the mechanisms to remove or replace a manifest. If we merge this one and ScoopInstaller/Extras#16996, those who previously installed opencode from extras bucket won't update anymore.

Reference: ScoopInstaller/Extras#16996
cc: @z-Fng For discussion, how should we handle opencode now? I think at least we can add opencode-desktop to Extras. But should we add opencode to main and deprecate the manifest in extras?

[itsrainingmani]

We agree that it should be happened, but currently we are lacking the mechanisms to remove or replace a manifest. If we merge this one and ScoopInstaller/Extras#16996, those who previously installed opencode from extras bucket won't update anymore.

Reference: ScoopInstaller/Extras#16996 cc: @z-Fng For discussion, how should we handle opencode now? I think at least we can add opencode-desktop to Extras. But should we add opencode to main and deprecate the manifest in extras?

I'm not super familiar w/ scoop internals. Is it possible to show a message during install/update saying that the package is deprecated and has been moved to the Main bucket?

[chawyehsu]

The only "good" way to handle this situation is keep opencode in the extras bucket, but remove the autoupdate check and add note of deprecation and migration to main/opencode. Then extras/opencode could be deleted after a certain period of time.

[z-Fng]

We agree that it should be happened, but currently we are lacking the mechanisms to remove or replace a manifest.

Exactly.

The only "good" way to handle this situation is keep opencode in the extras bucket, but remove the autoupdate check and add note of deprecation and migration to main/opencode. Then extras/opencode could be deleted after a certain period of time.

The GUI and CLI versions currently have separate download URLs. Does it make sense to turn opencode in Extras bucket into a full GUI package (with CLI support) and add the standalone CLI version to Main bucket as opencode-cli?

• https://github.com/anomalyco/opencode/releases/download/v1.1.21/opencode-desktop-windows-x64.exe
• https://github.com/anomalyco/opencode/releases/download/v1.1.21/opencode-windows-x64.zip

[chawyehsu]

Does it make sense

Yes but that does not match their products' naming. So, given the choice, I would prefer to follow their official naming convention.

[z-Fng]

The only "good" way to handle this situation is keep opencode in the extras bucket, but remove the autoupdate check and add note of deprecation and migration to main/opencode. Then extras/opencode could be deleted after a certain period of time.

Following this plan, should we keep the autoupdate check and add a 'scheduled deprecation date' note to the extras/opencode as well? Otherwise, users who already have extras/opencode installed will never trigger an update and will miss the migration warning in the notes.

[chawyehsu]

should we keep the autoupdate check and add a 'scheduled deprecation date' note to the extras/opencode as well?

Considering OpenCode's current update frequency, removing autoupdate with the next Excavator update would allow downstream users to receive both the "final" update and a deprecation note, although this seems a bit cumbersome. Adding only deprecation notes is a gradual solution.

[z-Fng]

Considering OpenCode's current update frequency, removing autoupdate with the next Excavator update would allow downstream users to receive both the "final" update and a deprecation note

Exactly.

The only "good" way to handle this situation is keep opencode in the extras bucket, but remove the autoupdate check and add note of deprecation and migration to main/opencode. Then extras/opencode could be deleted after a certain period of time.

@Lutra-Fs, what do you think? If you're okay with it, let's move forward with this plan.

[Lutra-Fs]

Considering OpenCode's current update frequency, removing autoupdate with the next Excavator update would allow downstream users to receive both the "final" update and a deprecation note

Exactly.

The only "good" way to handle this situation is keep opencode in the extras bucket, but remove the autoupdate check and add note of deprecation and migration to main/opencode. Then extras/opencode could be deleted after a certain period of time.

@Lutra-Fs, what do you think? If you're okay with it, let's move forward with this plan.

I'm on board with this plan and will go ahead and merge this PR now.

[Lutra-Fs]

/verify

[github-actions]

All changes look good.

Wait for review from human collaborators.

opencode

• Lint
• Description
• License
• Hashes
• Checkver
• Autoupdate

Check the full log for details.

[scillidan]

Thanks for your review!