5

The general software release process is alpha, beta, rc, release.

I am building a release for an embedded target, containing everything: boot loader, root file system, kernel, and the application software.

So one produces a release candidate, it gets fully tested and everyone is happy with it. However, the version (containing the fact it is a release candidate) is embedded in the release; in my case a file in the root file system (for example 4.0-rc5).

The process for making the release is a shell script which basically bundles everything together (it doesn't rebuild anything). The version file would need to be changed before the release was rebuilt.

I have a restriction that I cannot rebuild the release once it has been tested, otherwise it all needs to be tested again.

What is a viable process to promote a release candidate to an actual release?

5
  • if the no-rebuild-after-test restriction is firm, then perhaps you have to accept the extra work of having the (99% unchanged) release re-tested?
    – Jeff Schaller
    Mar 1, 2016 at 18:49
  • Yes, that's the way I'm leaning... Although I have just thought, maybe I could get away with generating the version file at installation. In this case it would move the [future] test dependency to the install of, rather than the operation of, the released software (with the exception of things that need to read that file...hmm - I suppose a default could exist).
    – Martin
    Mar 1, 2016 at 20:20
  • 1
    This sounds more like a question for Software Quality Assurance & Testing: there's nothing specifically about Unix here and it's more about development (that we don't do here) than about usage and administration. “What do others do” isn't what Stack Exchange is about, but your the base question here is fine. I've flagged your question to be moved, please do not repost unless advised to do so by a moderator. Mar 1, 2016 at 23:07
  • @Gilles I applaud your comment regarding "what do others do" not being SE friendly. That said, there are industry wide best practices (and in some cases, standards like ITIL release management) that will apply here. Usually, I'm not a fan of justifying a question based on the existence of an answer, but I believe this is canonical enough (while, strangely, not being too broad) to be a good fit. Good spot and thanks for the migration.
    – corsiKa
    Mar 2, 2016 at 6:28
  • 2
    What level of risk are you willing to accept? It's rare, but I've seen things as small as changing a release number break things. May 31, 2016 at 11:31

3 Answers 3

2

I agree with the no rebuild after test concept, things don't always build the same. Strange but true. I've seen one build that was influenced system load. But more likely is a risk of the build machine changing (updating modules or dependencies) during the regression cycle.

Why include the fact its a release candidate in the version label? why not just release the last build that passed testing.

Instead of: 4.0-rc5 use 4.0-05 or 4.0-12548562 Who cares? they're just numbers. You could always using the package name or location to indicate the release status.

2
  • Downvoted because computers don't magically decide to do something different. If building the exact same thing twice has different output then that's a sign that something's wrong. If you really want to avoid updated modules or dependencies, the answer is to start managing your modules and dependencies, not to keep building and testing versions until you have one that works and then laboriously trying to turn that same package into the release version. What will you do if one of the modules or dependencies needs an urgent update for security reasons?
    – Cronax
    Sep 25, 2017 at 12:48
  • 2
    I think you've missed my point; which is that if you always build release packages there's nothing more to do. It reduces the risk of problems you haven't anticipated. There's a good chance we're working on different platforms so it may not be an option for everyone
    – shedfly
    Sep 27, 2017 at 0:34
1

If you do not want to rebuild the code make sure the version number is always loaded from a central configuration file. Now you only have to change the file contents, seems pretty easy not?

I have a restriction that I cannot rebuild the release once it has been tested, otherwise it all needs to be tested again.

This is major bullshit. If the only thing you changed is the version number and you used the same build-script and the same codebase, re-testing seems an utterly waste of time and resources. The process is identical, so is the end result. Anyone voting for a new regression test run is crazy in my perspective.

Estimate the risk with the version number change. Is it used anywhere which could lead to problems? Probably not. Else write some automated tests to cover these situations so you can re-test them quickly. The only risk I can come with is that increasing the length of the version number could increase the overall package size making it not fit on the embedded device, but even this chance is very slim.

1
  • 1
    not major bs, time has changed which introduces an opportunity for things involved in the the build process to change. You would definitely hope not, but it is an additional risk.
    – CrashCodes
    Mar 13, 2020 at 20:56
0

In my experience, which I admit has often been of my own crafting and almost always specific to Red Hat / Fedora, I have a full suite of detailed tests to run against the release candidate package and a much smaller suite of simple verification tests to run against the repackaged release version. I've been able to get away with this by pointing out that the build process is identical between the rc and release packages, and that it pulls from a designated tag in the repository (be it git or SVN).

1
  • I would agree if this was an application package, where you can run automated tests, but most of the testing that is required in my case needs that human element.
    – Martin
    Mar 1, 2016 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.