release process for 1.0

[ViralBShah]

Do we fork off the codebase for 1.0? We may want to get rid of a number of things from that branch, as it is prepared for release. This issue can also track all the things that are removed and stay only on the development branch.

[StefanKarpinski]

Yeah, maybe. Let me look into successful git-based release processes for projects like ours and get back on this.

[JeffBezanson]

So far I doubt we have the luxury of experimental features. Everything is a frantic attempt to get essential functionality.

[StefanKarpinski]

Yeah, I agree with this. Let's release 1.0 solidly, regroup, and then start worrying about this.

[ViralBShah]

I meant removing j files that will not be part of the release, removing attic, adding release specific docs and such things. I agree that we are frantically working to get essential functionality.

[ViralBShah]

Just a thought - while we keep referring to the release as 1.0, I don't think the full julia is 1.0. The core language is probably good enough for a 0.9, but standard library is surely at 0.5.

Should we release at 0.5 for now? In general, we may want future releases to be backward compatible with the 1.0 core language - and perhaps we should go to 1.0 after having a couple of intermediate releases.

[StefanKarpinski]

That's fair. Version inflation seems to be in these days though.

[JeffBezanson]

If we remove attic where will those files go?
The only file I'm not sure what to do with is vcloud.j, which only works in the terremark environment. Maybe it should go to attic.

[StefanKarpinski]

I think the idea is that attic gets removed from the release version but can stay in the development version, which seems reasonable enough.

[StefanKarpinski]

The basic idea is that there's three stages of readiness for production:

1. branch: experimental, doesn't really work yet, don't merge into master because it will break other peoples systems.
2. master: everything works so people can develop against it, but things that are maybe not ready for prime-time general usage may still be left laying around as long as they don't get in anyone's way (e.g. vcloud.j or latin1.j).
3. release: not-ready-for-prime-time stuff removed from master; specific releases are tagged with appropriate names.

[JeffBezanson]

Sounds good to me. So it seems all we need to do is make a release-1.0 branch at some point, then eventually tag one of its commits as the 1.0 release. I assume after that point only critical bug fixes are allowed in the release branch, and those fixes should be made in the release branch then merged into master if applicable? Then future commits in that branch can be tagged as 1.0.1 etc. if we want.

We probably shouldn't create the release-1.0 branch for at least another month, since at this point there would be too much merging back and forth due to things generally being in flux.

[StefanKarpinski]

Yeah, that's about it. I'm not sure we need a release-specific branch, just a general release branch and we keep not-fully-ready things off of it. The 1.0, 1.0.1, etc. tags will all be on that branch.

[JeffBezanson]

GCC keeps multiple release branches so bug fixes can be applied to earlier releases. If somebody depends on the gcc 4.4.x series, they can go from 4.4.1 to 4.4.2 to get bug fixes without disturbing anything else, even when the current version is 4.7.0. I guess we can do that by making new branches off the release branch if necessary?

[StefanKarpinski]

Yeah, I'm just figuring that's kind of overkill for us at this point. Although maybe we should.