I’m sorry for the late announcement. Here’s a tentative schedule for the 3.5 release.
July 21: Branch for 3.5 release.
- All features should be near completion. Changes to complete existing features will be accepted until the end of testing phase I. But they should *not* be major (i.e., large) changes. If they are, they may be rejected.
July 21-27: Testing Phase I.
- Binaries will be available for general testing.
July 28-Aug 3: Fix bugs from Testing Phase I.
- At this point, all features should be complete. Any features which aren’t need to be turned off by default.
Aug 4-10: Testing Phase II.
- Only critical bug fixes accepted. Binaries will be available for general testing.
Aug 11-17: Fix bugs from Testing Phase II.
- The bugs fixed here are release blockers. Ideally, we won’t need a Testing Phase III.
I’m sorry for the late announcement. Here’s a tentative schedule for the 3.5 release.
Hi Bill,
I would like to propose a slight change to the release process. Instead
of naming the release tag directory RELEASE_XY, it would be better to
use RELEASE_XYZ to make it easier to support dot releases in the various
release scripts. Here is a documentation patch for the proposed change: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140616/221946.html
If there are no objections to this, then I will create aliases for the
3.4.2 tags using this new naming convention and then update the release
scripts. I think we will want to use 3.4.2 as the baseline when we check
3.5 for regressions, since in theory it has less bugs than 3.4.0
While you're at it, would be good to update the trunk script as well,
not just the release_350 branch.
I'm also adding some -arch / -extra so that we can build it in the
same way we run the tests and only build the appropriate back-ends
(ARM+AArch64 for both ARM and AArch64 binaries, in our case). Other
embedded/specific vendors might want to use that as well.
