LLVM 3.3 dot releases

Hi,

A few months ago, I mentioned I was interested in helping to make dot
releases for LLVM 3.3. Now that 3.3 has been released, I would like
to kick off the process of collecting bug fixes and merging them into the
3.3 branch.

I reviewed the previous discussion about dot releases:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060821.html
and I've come up with the following dot release 'rules':

+ Dot releases will follow the same procedure as major releases, which
  means stable patches must be approved by the appropriate code owner and
  that dot releases will have the same testing and qualification requirements.

+ No regressions. If a patch to the stable branch introduces a regression
  that cannot be fixed, it will be reverted.

+ Participation from developers is optional. If developers don't have
  time to help with issues in the stable branch, they do not have to.

I'm sure we'll need to amend or add to these rules as we work through the
dot release process, but I think this list is a good starting point.
So, with these rules in mind, I would like to volunteer for to be the release
manager for the 3.3 dot releases, which means I would be responsible
for overseeing the release process and also making commits the 3.3 branch.

I'll just throw it out there that we should aim for a dot release in two
months. I don't want to set anything in stone, though, because I think
that we may want to adjust this depending on how much activity there is
in the stable branch.

What I'm asking for now from the LLVM community now is:

+ Approval to commit patches to the 3.3 stable branch (This is really
  a question for Chris).

+ Individual contributors who are interested in helping with dot
  releases in any way.

+ Contacts from projects that use LLVM and are interested in
  coordinating their releases with LLVM dot releases.

I'm looking forward to working with the community and making LLVM dot
releases a success! Thanks in advance to everyone for your help.

- Tom

Hi Tom,

We, at Parrot, are using LLVM/Clang for our various home-made cpus / dsps.
This is done on private backends, but I am interested in participating to the
dot releases, as this is essentially what I am doing internally : select
patches to fix bugs to the current release --- beside developing the backends
:slight_smile:

FWIW, I also participated to the 3.3 release.

Cheers,

What I'm asking for now from the LLVM community now is:

+ Approval to commit patches to the 3.3 stable branch (This is really
a question for Chris).

Go for it.

-Chris

I'm happy to run the regression tests and build binaries, as I did for the 3.3 release. I can do this for 32 and 64bit builds on Ubuntu 13.04.

Ben

+ Participation from developers is optional. If developers don't have
  time to help with issues in the stable branch, they do not have to.

This may be very hard on the interested parties in the long term. I agree
that we should not force the dot-release on everyone as of now, but if it
becomes an accepted policy, I think people should start thinking about it
more often.

That doesn't mean people will have to have several trees to test on, but
we'd have to have build-bots on the stable release covering at least the
basics, so to make the process more automatic and painless to all.

+ Individual contributors who are interested in helping with dot

  releases in any way.

I can always re-run the release tests on ARM+Linux, no problems.

Would be great if you could change the test-release script to account for
that change beforehand, so that release testers can do that seamlessly.

Currently, we have "rcN" and "final", we should move to "rcN.M" and "dotN"
or something similar, to account for the dot releases... So:

rc0.1 -> rc0.2 -> rc0.3 -> dot0 -> rc1.1 -> ... -> dot1 -> ...

So that, in the script, we chose: "-release 3.4 {-rc2.1 or -final}| and the
script will checkout the correct tag of the correct branch.

Of course, to not disrupt the current release process, "-rc1" would have to
alias to "-rc0.1" and "-final" aliasing to "-dot0".

cheers,
--renato

Hi Tom,

This is a very sane requirement and I concur binary and API compatibility
should be enforced.

cheers,
--renato

Will LLLVM dot releases include fixes for Clang as well?

> + Participation from developers is optional. If developers don't have
> time to help with issues in the stable branch, they do not have to.
>

This may be very hard on the interested parties in the long term. I agree
that we should not force the dot-release on everyone as of now, but if it
becomes an accepted policy, I think people should start thinking about it
more often.

That doesn't mean people will have to have several trees to test on, but
we'd have to have build-bots on the stable release covering at least the
basics, so to make the process more automatic and painless to all.

+ Individual contributors who are interested in helping with dot
> releases in any way.
>

I can always re-run the release tests on ARM+Linux, no problems.

Would be great if you could change the test-release script to account for
that change beforehand, so that release testers can do that seamlessly.

Currently, we have "rcN" and "final", we should move to "rcN.M" and "dotN"
or something similar, to account for the dot releases... So:

rc0.1 -> rc0.2 -> rc0.3 -> dot0 -> rc1.1 -> ... -> dot1 -> ...

So that, in the script, we chose: "-release 3.4 {-rc2.1 or -final}| and the
script will checkout the correct tag of the correct branch.

This sounds like a good idea to me, I can work on updating the script.

-Tom

Definitely no API changes allowed. I think it makes sense to keep the
ABI stable as well. My guess is most users would prefer this.

-Tom

Will LLLVM dot releases include fixes for Clang as well?

I was planning on dot releases for clang and llvm.