0.1.0 Release Schedule

[markmandel]

All plans seem to align to announcement of the 0.1.0 release on the 15th of July!

This is the schedule I would propose leading up to that - comments and feedback definitely welcome.

This is also keeping in mind that Sweden is on holiday, the week of the 4th of a 3 day week in the US, and the week of the 12th of the Google for Games Developer Summit (and then after that is virtual GDC) - so time is probably limited for everyone - so an aim to keep surprises to a minimum over the next couple of weeks.

• 8th of July
  • Do a refactoring and feature freeze so that there are no surprises leading up to the release. (or maybe "minor PR's only").
  • Create the release issue, and start going through the release checklist
  • Submit the release PR: changelog, version changes, etc
• 9th of July
  • Merge the release PR.
  • Finish all of the release checklist, except for announcements, and publishing to cargo.
  • Create release with release artifacts.
  • Submit the 0.1.0 release.
• 12th of July
  • Focus on documentation / onboarding experience.
• 14th of July
  • (late us pacific) make the repository public.
  • Publish crates.
• 15th of July
  • Announcement blog posts goes live.
  • Add blog posts to README
  • Finish release checklist.
  • Close this ticket.
  • Party 🥳

@luna-duclos @iffyio @XAMPPRocky - how does that sound to you?

[XAMPPRocky]

how does that sound to you?

I don’t work during the weekend, but I am working through July, so I’d like to have till EOD Monday or Tuesday to get any final touches opened and reviewed. Other than that it looks good to me.

For the release announcement, should we also have a announcement on GitHub Releases that gives a short summary and links to both blog posts? That gives us a single link to share amongst developers.

[markmandel]

I don’t work during the weekend, but I am working through July, so I’d like to have till EOD Monday or Tuesday to get any final touches opened and reviewed. Other than that it looks good to me.

That's totally reasonable! Shall we say freeze on Wednesday then?

For the release announcement, should we also have a announcement on GitHub Releases that gives a short summary and links to both blog posts? That gives us a single link to share amongst developers.

Oh thanks for the reminder! I was going to suggest linking the blog posts from the front page README, since there is so much good info on there. Makes sense to edit the release notes and add it in there too 👍🏻

[XAMPPRocky]

Shall we say freeze on Wednesday then?

That sounds good to me, though thinking about it, I wonder if instead of freezing we should "release", since the repository is still private we can do everything up to making it public and have it ready on Wednesday/Thursday, rather than stacking those tasks closer to the release. That would allow us more time to check everything looks right, and the release behaves correctly.

This also brought up have we thought about our release schedule? Do we want to have a regular schedule, feature based, or ad-hoc release schedule? Personally I prefer a regular interval, as it ensures the latest master is always available in a timely manner, and stops releases from getting too big, though of course it's more work. In terms of what kind of interval I could imagine having a bi-monthly release, that would allow 2 meetings between releases (one where we can look back at the previous release, and the other to discuss the next release). That would be six releases a year.

[markmandel]

That sounds good to me, though thinking about it, I wonder if instead of freezing we should "release", since the repository is still private we can do everything up to making it public and have it ready on Wednesday/Thursday, rather than stacking those tasks closer to the release. That would allow us more time to check everything looks right, and the release behaves correctly.

The only thing we can't do is release to crates.io, since it would be public there. But yeah - we could do just about everything else 👍🏻 and push to crates.io on the 14th.

Publishing to crates.io freaks me out a little, just because I've never done it before 😄 I've no issue with anything else. But once the release is tagged, and there is a feature branch, it's easy enough to checkout and do the cargo publish from that snapshot.

We just need to make sure we don't break docs between then and the announcement.

This also brought up have we thought about our release schedule? Do we want to have a regular schedule, feature based, or ad-hoc release schedule? Personally I prefer a regular interval, as it ensures the latest master is always available in a timely manner, and stops releases from getting too big, though of course it's more work. In terms of what kind of interval I could imagine having a bi-monthly release, that would allow 2 meetings between releases (one where we can look back at the previous release, and the other to discuss the next release). That would be six releases a year.

Ditto - I'm a huge proponent of timed releases as well! 🙌🏻 At a previous meeting (I think this was before your time), this was the policy we came up with:
https://github.com/googleforgames/quilkin/blob/main/CONTRIBUTING.md#releases

At the monthly community meeting it will be decided if a release should be built.

Seemed like a good first step, and then we can see what sort of velocity we maintain post release, especially as more find the project, and we can look to adjust. I like a 6 week release cycle personally (with/without a release candidate), but that's also just what I'm used to 😄, so no massively strong opinions here.

Thankfully our current release process is pretty lightweight, so it's not onerous to do, even if it is once a month in the early days (especially if we aren't doing an RC release).

[XAMPPRocky]

I like a 6 week release cycle personally (with/without a release candidate)

I'd have no problem with six weeks other than it would need to not fall on the same week as Rust's six week release schedule, as that would double up releases for me.

[markmandel]

To come back around to the original intent of this issue:

I'm strongly advocating that we take a release with the current documentation and feature set as it currently stands. Pretty much all the PR's in the release milestone are wide reaching across both API surface and documentation (structure, correctness and hosting platform) -- which seems extremely risky to me in as we would be releasing next week.

They are all great PR's but I don't think we can realistically implement them and also ensure everything is stable, correct and a good onboarding experience for users before the 15th. This feels like it's being rushed, and that's a concern to me -- when I don't think there is any reason for us to rush through this.

[XAMPPRocky]

I don't feel strongly about it, so I'm fine with that but I also don't see the risk, we're releasing 0.1 of a Git repository, CI being green is as best an indication we have to the stability as anything else, and if someone finds a bug or a typo, that's what patch releases are for. Don't let perfect be the enemy of good and all that.

[markmandel]

I don't feel strongly about it, so I'm fine with that but I also don't see the risk, we're releasing 0.1 of a Git repository, CI being green is as best an indication we have to the stability as anything else, and if someone finds a bug or a typo, that's what patch releases are for.

In my experience, first impressions matter, so if our initial onboarding experience is bad, then it takes a lot for people to come back. And 9/10 times, they won't necessarily tell you that it's broken.

I'd like to focus on the next few days: reviewing the documentation, fixing up any TODOs in the docs, making sure our examples all work with published images, etc -- not double checking everything we've changed every day as a new big change lands, especially since we can't turnaround fixes very fast.

I want our new people to come and have as smooth an overall developer experience as possible with the platform we have.

Don't let perfect be the enemy of good and all that.

Exactly 😄 The code base is fine the way it is now, let's not mess with it for the time being, and give ourselves some room to breathe and bake in what we currently have for next week.

[markmandel]

... So unless there is any objection, I'll merge my PRs, and start cutting a release today, get in the release PR today so I can merge and start building artifacts tomorrow (assuming nothing goes wrong), get the release branch up, etc (basically do everything except publish to cargo).

This will also be good because then next week, we can double check any links we have in the announcement blog posts and any other materials point to the release branch/tag and that way they won't 404 over time, and we can double check that no links have broken between initial drafting and now (I already found a few on our end I needed to fix). 👍🏻

[iffyio]

SGTM!

[markmandel]

Finished checklist, and I assume you are all partying now!