Prepare for first alpha release

[Dinnerbone]

Opening this so we can track what we'd like to do/need to do before the first release, and get some opinions (mostly @Herschel's!) on it.

From my point of view, things we should do:

• Figure out a version scheme, for releases but also dev builds (#574)
• Figure out what it is we'll release and where:
  • Selfhosted to npm?
  • Browser extensions to Chrome and Firefox?
  • Desktop to Cargo?
  • Scanner/exporter to Cargo as separate releases, or roll everything up into subcommands of the desktop app? Or no release at all?
  • Copy all of the release binaries over to Github Releases, too?
• Prepare build/release scripts for all of the above
• Agree on a release frequency (when-needed, or regular cadence?)
• Start a changelog
• Expose the version to users in desktop & web

Things that are nice-to-haves:

• Revisit our homepage, add roadmap, how to contribute, issue tracker links, where to download Ruffle
• Dev blog? :D
• Possibly investigate into some crash collection service?

Anything else we should do, or anything we shouldn't? Is there anything we should wait and do first before looking into the first release, or can we already start aiming for it?

[Justin-CB]

Should we merge #404 before the release or wait till after? Another thing: it's only possible to load a temporary/unpacked extension until you quit the browser on firefox, but you can load them as until you remove them on chrome It might be good to also have binaries available thru github releases. It might be nice to have a simple GUI for running flash with ruffle, as well.

[Herschel]

• Release versioning:
  • For release builds, let's start at 0.1 and advance from there in a semver way.
  • <1.0 we would consider any public API unstable (although let's try to keep it stable).
  • For dev builds, we can use built (https://crates.io/crates/built) to snag the commit ID for a version.
  • Release locations:
  • The primary location for tagged releases should be on GitHub Releases and on the Ruffle website (possibly linking to GitHub Releases).
  • We should publish selfhosted to NPM too, as I've had some people ask about it. (I will need help here, as I'm not familiar with the npm ecosystem).
  • Publishing desktop to crates.io doesn't seem necessary (it seems an odd place for non-Rust-focused end-user apps), but I could be convinced otherwise.
  • Extensions should be properly packaged for the Chrome Web Store/Firefox Add-Ons page.
    • Firefox involves a signing process (https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/)
    • We should make an app page on the Chrome Web Store (unlisted to start)
  • Exporter would be nice to bundle as a subcommand, if possible. Scanner seems less important to me, but including it is no big deal.
  • Release frequency: No strong opinion here, although I'd prefer a "when it's ready" approach for our sanity.
  • Desktop GUI: Not necessary for first release; we can just keep a CLI while we consider how to approach this.
  • Website: @kmeisthax did some work here, and @pocketonion has been doing nice work on cleaning up the demo page. Maybe they could work together on that.

We should triage and label issues that we consider necessary for a first release.

@Justin-CB #404 isn't necessary for a first release as it's only the beginning of AVM2 work and won't add any functionality immediately. (I expect it'll be in by the time we do a release, though -- thanks to @kmeisthax for the patience until I get around to chugging through it.)

[KSXGitHub]

I had a GitHub CI (for my own project, completely unrelated to ruffle) that deploys everything: upload binaries to GitHub Release, publish NPM packages, publish cargo crate to crates.io, and updating AUR packages. You might want to take a look.

[Dinnerbone]

I suggest crates.io for desktop because rust-created-CLI tools are being published there, ie ripgrep. There's a category for them. https://crates.io/categories/command-line-utilities?sort=downloads

Until we decide to go crazy with publishing to package managers and stores, it'd be super convenient for people with rust installed to just cargo install ruffle and keep it up to date that way.

[Herschel]

Ok, seeing ripgrep and all of the other tools on there convinced me! cargo publish shouldn't be a huge burden anyway.

[Justin-CB]

Any changes to the public API or affecting the public API should be decided on before any release. For example, should we continue with the current polyfill settings or have a single setting for polyfilling everything(someone mentioned this in the discord, I think)?

[Herschel]

I have been leaning toward having the polyfill be a single setting:

• The original impetus for separate settings was the possible performance implications from adding MutationObserver, etc. to a live website.
  • But even the static/frames polyfill are becoming complex at this point.
  • The target audience of the polyfill are legacy pages where performance issues would be insignificant.
  • The extension will have to enable everything to work regardless. I guess these settings could be exposed via the UI? But I'd consider it a bug if a page had problems with a certain polyfill.
• In practice, I'm not sure how many people would actually think about enabling/disabling static vs dynamic.
• There are interactions between the settings that would be simplified if they were combined (for example, the behavior of "frames" depends on whether "dynamic" is set. Also, "plugin" has to run ASAP compared to the other functions).
• Any users that want significant control would prefer to use to JS API anyway (i.e., game portals).
• It reduces the API surface area that we have to test.

[Tiagoquix]

Hi, is there any updates on this? So far, we only have had pre-releases.