How to lock a baseline/snapshot and a build results

This post/question actually has a few questions in it. Geoffrey explained some of them, but I'll provide an 'answer' here as well, with a summary of what was already answered plus answers to other questions. Feel free to open up enhancement requests or RFEs for any behavior that is not present and you feel would be beneficial.

Note: These comments are as of RTC 6.0.5.

-Can I create a release from a build?
Yes. In the Eclipse RTC client, open up a build result, and select the "Create a release to associate with this build" in the "Associated Release" section in the 'Overview' tab. This will create a release object and associate it to the Build Result. This will also automatically un-check the 'Deletion allowed' checkbox as well so that the build result will not be automatically pruned or manually deleted . Note: Releases show up in the 'Releases' tab of the Project Area editor.

-Can I prevent the deletion of any build result?
In the Eclipse RTC client, open up a build result, and in the "General Information" section, un-check the "Deletion allowed" option. This will prevent the build result from being automatically pruned when more build results are created or from being manually deleted.

-Can I prevent the deletion of the build snapshot?
This can only be done by specifying what roles are allowed to delete 'any' snapshot in a Process Area. For example, you could change the owner of the snapshot to a stream which is contained in a process area (Project/Team Area) that has 'limited' ability to delete snapshots. Note: By default, all the snapshots associated with the build will be owned by the build workspace, and thus only the 'build user' should be able to delete the snapshots (so in general this restriction is probably good enough). But we tend to encourage moving the 'release snapshots' over to the 'stream' that represents the release. This makes the release snapshots easier to find.

-Can I prevent changing the snapshot/baselines?
(Reminder: a snapshot is just a set of baselines).
For the most part snapshots/baselines are immutable except for the ability to change the name and description (in which you would have to set up process permissions to dictate who can change this). Otherwise things like the ID of the snapshot/baseline cannot be changed, as well as the 'content' (such as the change set history, and the specific versions of the files).

-Can I lock a stream at the end of a release?
Creating a snapshot is one way to capture the state of a stream at the end of a release (although this generally would be done by a build as it creates a build snapshot). Another approach is to 'fork' the stream so that it forever is meant to 'sit' at that particular 'release', and use a different stream to represent the 'main' or 'head' stream.

If you do want to actually lock the stream for some reason, in RTC 6.0.2 we added a feature that lets you lock streams and components to prevent deliveries to the files in those streams or components. Stream and component locks work in a similar manner to file locks but apply to the entire stream or the entire component in a stream. When a stream or component is locked, any attempted deliveries by users who do not own the lock will fail with an appropriate error message. The user that holds the lock can still perform deliveries to the stream. A lock does not only prevent deliveries, it also prevents any operation that affects the files in the locked component or stream. For example, a component replace is also prevented.

See:
-New & Noteworthy Mention: https://jazz.net/downloads/rational-team-concert/releases/6.0.2?p=newsDetails#stream-locking
-Stream/Component Locking Demo Video: https://www.youtube.com/watch?v=b8QwzwUF2ZY
-SCM Command Line Client 'set lock' command: https://www.ibm.com/support/knowledgecenter/SSCP65_6.0.4/com.ibm.team.scm.doc/topics/set_lock.html

Prior to 6.0.2, one approach might be to add a deliver advisor in the process spec to restrict deliveries to particular streams. By protecting your stream by particular roles or users, you can effectively lock the stream down.
"http://jazz.net/library/article/215#protect_some" describes how to protect individual components in a stream, the same approach can be used to lock down the entire stream.