Suggestions for the release cycle

[pygy]

I know it has already been discussed and possibly rued out by some of the core dev, I'd like to make the argument for a rolling release cycle, and give suggestions on how to implement it smoothly.

I don't know if Julia in its current state is stable enough to adopt it yet (it sure wasn't pre-0.2 because of the Pkg issues, but once the major problems are sorted out, a rolling cycle will IMO make things easier for everyone.

The obvious advantage of rolling releases is that you keep an official binary with recent-ish features, which allow users and library authors to adapt gradually to the new features. Two releases a year would make sense for Julia (it works well for MATLAB and Ubuntu, for example). ITtstrikes a good ballance between stability and innnovation.

The main drawback is the potential rush to cram as much as possible features as possible, resulting in a botched release.

Here's what I suggest, based on what the ScummVM guys do, but I believe it is a common pattern:

• develop new features in branches. Once the authors feel a feature is stable enough they petition the lead devs to merge it into master. Publish daily builds, fix bugs as they come in master.
• merge master into feature branches on a regular basis.
• three or four weeks before the release date, create a release branch out of master, frozen for new features. Bug fixes only. Publish daily builds and encourage testing. You can still merge new features into the master.
• N (three to five) days before the date publish the firs RC. If a show stopper is found, release a new RC, with a new one N days delay. Minor bugs will wait for the point releases.
• Tag and release.
• Keep the release branch for point releases.

This kind of schedule releases the time pressure of the dev process. No stressful decision to be made.

The key points are having a few lead devs who decide what and when things can get merged, and the fact that you can keep the release branches for minor bug fixes.

Usually, devs self-police. But sometimes someone must take the decision to make the cut, and having clear leads helps there.

The number of lead should remain low, and the leaders must of course be on the same page. The three founders come naturally for the position.

Thoughts?

[vtjnash]

I'll try adding a few thoughts to promote discussion.

What you describe doesn't sound much different from the current situation. The hardest challenge right now seems to be that we still have half a dozen "release-blocking" open issues for 0.2 that need fixes.

What you describe sounds like a pretty stamdard release cycle and Julia seems to be headed for a 6 month cycle. The nightly builds we have for Ubuntu, and to a lesser extent, the prerelease binaries for Mac and windows are a rolling release.

Personally, I think I'm in favor of a 2 month cycle, which falls somewhere in between those two scenarios. Each release wouldn't get many bug fixes afterwards, but might get a few right away. It would get any features that are ready during the development window. I feel this gives a balance between stability and agility. But then there's the issue of release-blocking bugs and what to do about them...

[pygy]

The point of the scheme is to avoid the llarge release blocking issues, by having new features kept aside until they are mature.

This was not possible for v0.2, because of the package issues, but hopefully there won't be any problems of this scale in the future.

A two month cycle is more stressful for the lead devs. It may be doable if you switch the release manager for each cycle.

[JeffBezanson]

This discussion can go in #3827