Return to stable after testing development release

I have IPFire 2.27 (x86_64) - Core Update 167 Development Build: master/24c8e6a6 installed and now that stable Core Update 167 is released, I wish to return to stable builds. Pakfire doesn’t offer to install the stable version (Stable is selected in Settings, Repository).

I will be reluctant to test future development versions if I can’t move back to the stable version after testing is concluded.

Change /opt/pakfire/db/core/mine to 166, then use pakfire up upgrade to 167.

4 Likes

I’d like to see an option to do this from the web interface. Something as simple as adding an input box that displays and changes the contents of this file. The display of this input box could be limited to only show when Testing or Unstable is selected in the dropdown.

2 Likes

The procedure for reverting is not simple

  • reverting from testing to stable of the same core level does work, as described above
  • OTOH, reverting to stable, from an as yet unreleased testing core is problematic, because many settings and modules have been upgraded. Consequently, it should not be attempted.

The reversion issue was discussed in an earlier thread some years ago. Guidelines put forward then included:

  • advisable to maintain a separate device, running stable (as ARM users found, multiple test releases of core 167 produced an unworkable upgrade)
  • testing releases are oriented to more experienced users, who are likely to be able to document results, as well as being able to use command line to revert, if appropriate
2 Likes

I’m not so much interested in “reverting” which I take to mean 166 stable → 167 dev → 166 stable. I’m interested in 166 stable → 167 dev → 167 stable.

For example, I (and others) reported a bug having to do with DNS updates from DHCP leases. This was reported as fixed in 167 dev version so since I reported the bug, I wanted to test the fix (and report back if it didn’t work). The fix worked, 167 stable was released, and I wanted to return to the stable release(s).

Changing the contents of /opt/pakfire/db/core/mine worked but I believe there should be a way to do that in the GUI.

1 Like

An issue with doing that in GUI, is that less experienced users could change & save GUI settings, without adequate understanding of potential consequences. It would require a decision tree, built into the GUI procedure, to prevent the reversion to prior release, during testing phase.

Testing release of next core is often available only a few days following stable release of the current core, resulting in limited need for what you are seeking. I have two hardwares permanently on testing and a third on stable. I’ve also been given an Nanopi R1S H3, which I could now use to test the revised upgrade procedure from 166 to 167 stable, on arm6hl.

1 Like

You have convinced me… Just stay on the stable releases.

Testing of Dev releases is very important. The more testers the better for all users. There are recent examples of too few testers:

https://community.ipfire.org/t/core-update-167-requires-additional-step-for-arm-users-before-rebooting/7852

https://community.ipfire.org/t/cu-164-backup-issue/7614

including one issue that you were kind enough to participate in:
https://community.ipfire.org/t/dhcp-hosts-not-reliably-propagated-to-dns/3431/35

The above posts should convince you not to use your “main” (production) IPFire device for testing. And it should have convinced you to build up a “spare” (old) computer and assist in testing (on the spare).

IPFire :heart: testers!         ← new bumper sticker

3 Likes