I just started working for the first time with a product that’s delivered via the Linux RPM mechanism, rather than as a standalone installer, and realized that this makes the test / release cycle a bit more tricky.
When I was working with installers, we would just change the build numbering in our build system to mark a build as a test or release candidate instead of a development snapshot, and tell people to install only the candidate build for testing. The problem with doing that with RPMs is that if we change the numbering system, we’ll break the delivery mechanism and installed machines won’t be able to tell which is the latest version of the RPM any more.
The best way I’ve thought of to get around this is to put the candidate RPMs in a completely separate RPM repository, but this also gets complicated because we have multiple RPMs coming from the same repository that are on different release cycles, so we’ll be trying to pull the release candidate version of RPM A from the new repository while still wanting to get development snapshots of RPM B from the development repository.
This must be a pretty common issue for Linux software, so can anyone tell me the best practice ? Thanks in advance …..
One common methodology in the Linux world is to have a widely-publicized release number convention that indicates whether a build is development or release. For the Linux kernel itself, odd point releases (2.5, 2.7) are development, while even (2.4, 2.6) are releases.
A quick scan of the RPM guide seems to indicate that using a scheme like this may be the best bet.