Release Management Process

(Joël Lupien) #25

I can, if someone wants to write the release article ^^

Otherwise it will be for another time.


(Thomas Schaller) #26

I suggest we release one or more amethyst-*-betaN crates before we release 0.10. Is anybody opposed to this?

@Ellie @jojolepro @LucioFranco

EDIT: You can find the issue on the project board


(Lucio Franco) #27

I don’t know if this is a good idea to be honest, I think this will just be even more confusing since now there will be like another 12 crates that start with amethyst on We will have more issues come up because now we have three channels of change github, beta/preview, and released.


(Thomas Schaller) #28

Hmm, would do you suggest instead? How should we do release candidates?


(Lucio Franco) #29

I would say this would be a good idea if we released one crate but since we release a bunch its just a lot. So I would rather release a rc1 either to crates (don’t know if you can do releases like that) or just tag it on github.


(Thomas Schaller) #30

We can do releases like that, but @Ellie had concerns because it might clutter the version history and I’m unsure what will happen on sites like; if the version string starts with the version itself that might lead to the beta being displayed by default which would be suboptimal.

EDIT: One idea would be to start the version with beta-*, but we’ll have to check the effect of that to be sure.


(Lucio Franco) #31

Well, I think tagging a RC is just fine. Beta really means something else. We are doing a RC to catch final release bugs not to release a beta. So what I suggest is to tag the current commit with a v0.10.0-rc1 tag that indicates this is a release candidate. Then freeze PR merging, thats what this rc1 is for. Once, we are happy with the RC then we can create a commit to bump versions or do whatever else we need to do. Then follow the v0.10.0 release procedure. This should cause the least amount of friction and people can still pull the release candidate down via amethyst = { git = "...", tag = "v0.10.0-rc1"}.

1 Like

(Thomas Schaller) #32

Okay. I think you’re right that we should keep release candidates and beta/nightly separate. I just wanted an easy way to try out the master version of Amethyst without depending on git, but I understand your point.

I’m wondering right now, it would be lovely if the amethyst CLI could do this…

As for the release candidate, I’ll follow your proposal to use tags :+1:

1 Like

(Lucio Franco) #33

:+1: I think its actually better to depend on git for release candidates and then move to crates when the release is offical. Mostly, because we can tell people to look down to the tag which is a lot easier than a commit rev.


(Fletcher) #34

Betas, RCs, etc are not terribly useful unless you can get actionable feedback from the people who use them. This is quite rare in my experience. What would be useful is betas/RCs/whatever with analytics baked in that sent us crash reports and usage statistics automatically.

1 Like

(Lucio Franco) #35

I don’t know how people would like this though, seems very invasive at least in open source software.

1 Like

(Fletcher) #36

It’s super common in open source software and commercial software. Default to off, and give them a prompt to turn it on if they want.


(Azriel Hoh) #37

Notes from 0.10 release for getting list of contributors:

  • Use created:>YYYY-MM-DD filter in the amethyst, documentation and RFCs repos. Manually filtered usernames on text pad.
    This ensures we don’t miss people who do contribute in other ways than code.

  • Automating this is not trivial yet, need to handle paged results + manually filtering based on date.

    # TODO: Read next link from response headers
    # TODO: Request sort by PR date desc and stop reading next page when we get to the previous release date.
    curl '' > /tmp/closed_prs.json
    jq '.[] | select(.merged_at != null) | .user.login' /tmp/closed_prs.json | sort | uniq


(Thomas Schaller) #38

Something else I want to bring up: Do we want to only release according to schedule, or are additional releases okay, too? By that I mean breaking releases, because patches are something we definitely want to release.


(Fletcher) #39

My thoughts:

Patch releases are fine anytime.
Critical bug releases are fine anytime.
Feature releases I would suggest staying as close to a regular cadence as possible. Once we have more comprehensive tests and testing methodologies, I think we have better options. For now, we could do an alpha/beta release for people who want to try it out.


(Lucio Franco) #40

Update with 0.10

Instructions for actually releasing:

  • Go to each crate and bump the version including all their deps that are within the same repo that you are bumping.
  • Go to amethyst_core and run cargo publish --no-verify
  • then these crates in order run cargo publish
  1. amethyst_assets
  2. amethyst_config
  3. amethyst_derive (permissions need to be fixed)
  4. amethyst_audo
  5. amethyst_locale
  6. amethyst_network
  7. amethyst_renderer
  8. amethyst_animation
  9. amethyst_gltf
  10. amethyst_input
  11. amethyst_controls
  12. amethyst_ui
  13. amethyst_utils
  14. amethyst

then you’re done!

1 Like

(Lucio Franco) #41

Amethyst tools also needs to be updated with the latest release template.


(Joël Lupien) #42

And you also actually need to do step 2,3,4,5 from here Release Management Process

Also, I think we should add to the list that we lock the patch version of the dependencies. This should probably be in another conversation however.

1 Like

(Thomas Schaller) #43

Started working on this:

1 Like

(Thomas Schaller) #44

Quick (and bad) way to get all contributors for this release:

git shortlog v0.10.0..HEAD | grep "):" | sed 's/.\{5\}$//'
1 Like