Resolves#4730
I opted to link directly to the release notes of the updated version in
the `<description>` body, i.e. in the future it would link directly
v1.0.2's release notes at
https://ghostty.org/docs/install/release-notes/1-0-2. This thereby
implements the second option mentioned in the issue. It wasn't that much
harder than the third option, but if there's any particular reason _not
to_ link directly to a version's changelog page, I'll be more than happy
to modify this PR and implement the third option instead - in any case,
I had opened https://github.com/ghostty-org/website/pull/277 so that
https://ghostty.org/docs/install/release-notes is a valid page.
I also wrapped the current text `<![CDATA[ ... ]]>` just in case, as I
noticed this is a pretty standard practice in other apps that use
`<description>` to embed their release notes when using Sparkle -
[Sparkle's
documentation](https://sparkle-project.org/documentation/publishing/#embedded-release-notes)
says to do this so you can use unescaped HTML.
We've used a zip for the duration of the private beta but macOS users
expect a dmg. This commit changes both of our release workflows to begin
building a dmg instead of a zip.
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
This adds a new workflow for building and releasing _tagged versions_
of Ghostty. The workflow is triggered automatically by new tags in the
format of `vX.Y.Z` but can also be manually triggered by running the
workflow from the GitHub Actions UI.
Release artifacts are uploaded to a completely separate R2 bucket
with its own access policy, retention, API keys, and so on.
There is currently no way to switch between "channels" in the macOS
app. I will follow up with a separate commit to add this feature.
❤️👻
This is the icon that we'll launch Ghostty 1.0 with. It was designed by
Michael Flareup at PixelResort. It retains the style of the original
Ghostty icon by Alasdair Monk, but brings in the new Ghost character and
adds details that make it more Apple-like.
The new Ghost character is an important evolution from the original
since it separates us from looking too much like PacMan. The new Ghost
is more unique and recognizable to Ghostty (or, hopefully will be!).
The icon itself has more details: the aluminum around the edge has
texture for the large enough sizes, there are visible scanlines, the
glow of a screen emanates from the ghost.
The icon itself is stylistic more Apple-like than other platforms. I
think Apple icons tend to look very good in more environments than the
reverse and I'm a big fan of the Apple aesthetic so I wanted to bring
that to Ghostty for all platforms.
Removed check for plasma in build.zig, it installs it anyways now
Added executable permissions for ghostty_dolphin.desktop since Plasma
requires them for context menu items
The focus of this commit is to store the dSYM files associated with
official macOS builds. dSYM files allow us to map crash reports to
source.
The dSYM files are primarily uploaded to our official blob storage where
all releases are also stored. We also upload the dSYM files to Sentry
since I'm experimenting with using that for crash reproting (note:
manual crash reporting, no automatic network traffic).
This commit also changes our blob URLs for releases to use the full
Git SHA rather than a build number. This is much easier to trace back.
Adds an rc file for windows. An rc file is a source file given to the
toolchain that instructs it on what "resources" to embed inside the
executable. You can think of "resources" as files or data that get
embedded into the executable and can be accessed both by the application
at runtime or by the OS. The OS uses resources for things like getting
the icon of the executable or extracting the version of an exe for the
user. Note that exe resources can also be modified without having to
recompile/relink the binary.
Thanks to Squeek502 zig has its own "RC Compiler" so this should still be
buildable on all platforms.
In the RC file I've included some basic info and left in comments for
other info to be populated later. I've also included a manifest file
which starts out by telling windows that our exe will be DPI aware and
to use a slightly more modern look and feel for native controls.
The app.desktop file shipped with the default build presumes the install
location of the binary. Let the OS determine the executable through it's
normal PATH variables.
Flatpak support has been a HUGE pain to keep working, the builds take
forever and cost me real money, and there are very few users. Ideally,
we want to just use native system packagers for each distro. I thought
Flatpak would make it easy to support many distros but that ended up
being false.
Inspired by #413.
This modifies the .desktop files so that it's possible to right-click on
the Ghostty icon in a dock and get the "New window" action.
Apparently this is how you implement that in GTK applications. In order
for us to also get "New tab", we'd have to implement a CLI flag, I
think.
