tl;dr - Let’s create monthly Cesium releases, and pass around the responsibility for creating them.
Since before Cesium was on github, we have released it based on user requests. I’d like to suggest that we start doing regular releases so users know when to expect updates, and to show the stability and activity of the project.
Since I am anti-process, I’d like to see us do the simplest possible thing:
On the first business day of the month, someone verifies master is stable, updates CHANGES.md and build.xml (this should be done on a branch), and releases Cesium by adding it to the downloads page and sending an email to the mailing lists with the CHANGES.md updates.
Dan - under Scott’s guidance - continues to do this for the next couple of releases, and writes a wiki page with instructions. At any point, he can pass the responsibility to someone else, or someone else can ask for it. And so on.
For now, we continue increasing the beta release number: b7, b8, …
As we all know, releasing at a fixed time reduces schedule pressure because the date is fixed - whatever features are in master go in.
Given our careful pull request reviews, master should always be stable, so I suspect we can release in one day - well, one hour. Master should always be “ready to ship” as Joel says. If we can’t, then our upstream practices are broken, and we should fix them. I think our practices are awesome, and that we won’t have a problem.
I don’t want to create a hierarchy with a “release manager”, so I suggest the flat structure of sharing the responsibility of releases. It spreads knowledge, avoid stratification, avoids a single point of failure, and is beautifully unstructured.
Ideas? Suggestions? git release best practices we should embrace?