servo: Add version 0.0.1

[cscnk52]

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

@chawyehsu Please take a look at this PR.

[coderabbitai]

Walkthrough

Introduces a new package manifest file for Servo v0.0.1, a cross-platform rendering engine. The manifest defines installation metadata, download configuration, binary paths, and automated version checking for Windows x64 MSVC builds.

Changes

Cohort / File(s)	Summary
Servo Package Manifest bucket/servo.json	Adds release manifest defining Servo v0.0.1 for Windows x64 (MSVC), including version metadata, download URL and hash verification, extraction configuration, executable entry point, and automated version checking via GitHub repository integration

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A manifest hops into view,
Servo's Windows journey anew!
With checksums and shortcuts in place,
Updates will run at a rabbit's pace.
Thump, thump—automation takes flight! 🚀

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	The PR description follows the template structure with both required checkboxes marked as completed (conventional PR title and reading the Contributing Guide). However, the description is largely incomplete and fails to meet critical requirements outlined in the template itself. Most significantly, the template explicitly states that "it is mandatory to open a relevant issue (either Package Request or Bug Report) for discussion with the maintainers, before creating any new PR," yet the description contains no linked issue (the "Closes #XXXX or Relates to #XXXX" section remains unfilled with placeholder text). Additionally, the description provides no substantive content beyond the template structure—it merely marks the checkboxes and adds a reviewer mention, without describing the PR's purpose or changes in the body content.	The author should add a reference to a linked issue using either "Closes #XXXX" or "Relates to #XXXX" format to satisfy the mandatory pre-PR requirement. Additionally, the description should include substantive content that explains the purpose of adding the Servo v0.0.1 manifest, any relevant context, and confirmation that the mandatory pre-work (searching for similar PRs and opening a discussion issue) was completed before submitting this PR.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "servo: Add version 0.0.1" directly describes the main change in the pull request, which is adding a manifest file for Servo version 0.0.1. The title follows the repository's conventional format of <manifest-name>: <summary>, is concise and clear, and allows a teammate to understand at a glance that this PR adds a new version for the servo package. The title accurately represents the content of the changeset without unnecessary verbosity or vagueness.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

All changes look good.

Wait for review from human collaborators.

servo

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

Check the full log for details.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

bucket/servo.json (1)

16-18: Consider adding pre-release handling to checkver (optional).

The Servo project plans monthly updates, and v0.0.1 is marked as a pre-release version. The current checkver configuration will pick up all GitHub releases without filtering. For now this is acceptable, but consider adding pre-release detection logic if future stable (v1.0+) releases are planned to avoid version skipping.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1277cb4 and 2ce6d29.

📒 Files selected for processing (1)

• bucket/servo.json (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: PullRequestHandler
• GitHub Check: WindowsPowerShell

🔇 Additional comments (4)

bucket/servo.json (4)

1-5: Metadata fields are accurate.

The version, description, homepage, and license align with Servo's official messaging and MPL-2.0 license.

---

6-8: Verify the release artifact hash.

The URL points to a valid Servo v0.0.1 release, but the SHA256 hash should be verified to ensure it matches the actual artifact on GitHub.

To verify the hash integrity, you can:

1. Download the release artifact: https://github.com/servo/servo/releases/download/v0.0.1/servo-x86_64-windows-msvc.zip
2. Compute its SHA256 hash using certutil -hashfile servo-x86_64-windows-msvc.zip SHA256 (Windows) or sha256sum servo-x86_64-windows-msvc.zip (Linux/macOS)
3. Compare it against the value on line 7

Alternatively, check the GitHub release page for an official hash if provided.

---

9-15: Binary and shortcut configuration looks good.

The executable path and Start Menu shortcut are correctly configured for the Windows release.

---

19-21: Autoupdate URL pattern is correctly configured.

The $version template variable will be properly substituted by Scoop's update mechanism to construct valid release download URLs.

[z-Fng]

Is this a stable release? If so, perhaps we can add it to the Extras bucket instead.

If not, we could rename it as servo-pre? When servo releases a stable version, we can then add it to the Extras bucket.

[cscnk52]

not a stable release.

servo is a project trying using Rust rewrite browser kernel, it will be not stable in a long time, so i think not add pre suffix is better.