Amethyst Versioning and Release Process

(Azriel Hoh) #1

Hiya, is anyone in favour / opposition to the following:

  1. Moving all tests to a single workspace_tests crate
  2. Versioning all workspace crates to the same as the top level crate
  3. Make releasing / publishing a simple version bump + loop to run cargo publish for each crate

Motivation for:

  1. Faster build times, fewer build artifacts, and don’t have to comment / uncomment crates during publishing.
  2. Simpler – don’t need to trace what version of what member crate relates to what amethyst version
  3. Publishing becomes a cheap / easy operation, so there’s no impedance to publishing a new version whenever

Motivation against:

  1. Tests live separately from logic, need to recreate file structure
  2. Maybe nothing changed in this crate version, but it got bumped anyway
  3. none?
(Joël Lupien) #2

For me this is a major issue. Having unit tests right next to what they test make them much easier to use and maintain.

(Azriel Hoh) #3

Re:tests living next to code, (from these eyes) it’s not too much of a pain point that they live in separate files – there are existing ecosystems that do this (Java, Node, Ruby). It’s certainly made easier by convention and tooling – a text editor that can jump to file tends to be good enough in practice.

The other perspective, building and linking amethyst 18 times is also a pain point, and so is doing the publishing dependency dance, which I can’t find in this moment (@distransient may remember where that’s written down).

Idrealistically, I’d like to work towards "releasing amethyst is simply git tag; git push", so that when issues like #2162 come up, they can be fixed / released within an hour. But perhaps my ideals can’t be extended this far.

(Kel) #4