Build protocol for 2.1-RCn

phil.davis

I was just updating to 2.1-RC0 and got "Downloading complete but sha256 does not match." When I started downloading it was offering a build from 23 May 2013. During the downloading time, another build happened to finish, so the sha256 indeed did not match. I ran the download again and am now on:
2.1-RC0 (i386)
built on Sat May 25 07:43:14 EDT 2013
FreeBSD 8.3-RELEASE-p8

That means that 2.1-RC0 is like 2.1-BETAn, in that the builder runs every so often and looks to see if there are any new commits to the 2.1 branch. If so, it builds new snapshots. So one person's 2.1-RC0 is different from another's, we still have to look at the built date to verify that 2 installs are running the same code.

I had imagined that at the RC stage, automatic builds would be stopped, so that RC0 is a fixed thing. And that every so often, when there are some really useful fixes committed, the next RC1, RC2… would be built. That way it is clear that RCn is the same thing for everyone who runs it.

Can the devs clarify the process from here?
At what point are "fixed" builds made that have an RCn number and are "set in concrete" as being potential candidates for release?

c0urier

I had the same impression @phil.davis.

asterix

Ditto.

If I am not mistaken 2.0 RCs were released in a similar fashion.

chpalmer

@asterix:

Ditto.

If I am not mistaken 2.0 RCs were released in a similar fashion.

and the 1.0.x branch.

jimp

For 1.2.x and the some 2.0 RCs we would take one snapshot and officially call it "RCx" and actually sign it and put it up like an official release.

Currently we treat them more like snapshots, which is more realistic. There isn't really anything more special about RC0 than the BETA0 from just before it, it's all incremental improvements and we decided that it was stable enough in general to move the label to RC0.

We may actually put out an 'official' RC image now and then but IMHO that gives people a false impression that they can just keep running that and never update to the RELEASE version (I still encounter a lot of -RCx images out there from various versions). They should be treated more like higher-quality snapshots and not like they are unique/special in some way. The main difference between the BETAs and the RCs is that we have branched RELENG_2_1 off and are more careful about what commits will make their way into 2.1 proper as opposed to those left for 2.2.

Technically speaking, even the release is a snapshot, built the same way, just tagged as RELEASE. Having a special build process for certain types of images would just leave more room for error.

phil.davis

Thanks for the policy info. Now it is clear, we all know that the "built on" date-time stamp is what really counts to know what code is running when reporting problems with pre-release code of any type (ALPHA, BETA, RC…).

cmb

For 2.0-REL and 1.2-REL we did push a specific RC out to the mirrors but still had snapshots labeled with the same RC label running so there really wasn't a point in doing so. No RCx was the same as someone else's RCx, it's always been build date that's significant. The only time that's been any different is in the 1.0.x days when there weren't automatic snapshots.