Development versions: Alpha, Beta and Release Candidate explained

[franco]

Good day everyone,

TLDR: While the stable release is being maintained each stable release also bundles a development version which can be accessed from the GUI using System: Firmware: Settings: Release type "Development". We encourage everyone who can spare a helping hand to review the development release with us to produce better community releases.

We're trying something new for 17.1 with regard to ongoing 17.1 development period during what is also known as the 16.1 production period (February 2016 - July 2016).

While the release version will continue with the known versioning scheme 16.1.x, the development version is made up of three different phases prior to becoming 17.1 (and 17.1.x after that):

Alpha (17.1.a): The first phase of development, which is carried out in the first 3 months of our development cycle. In this phase, larger reworks are carried out that may need a few weeks to stabilise and may not be suited for production environments just yet. A typical change would be a FreeBSD version switch or rework of a crucial subsystem like the configuration management backend (config.xml) or 16.1's captive portal switch. Basically anything that may remove or replace original code without backwards compatibility. We focus on achieving a seamless binary upgrade path, but do not provide official images.

Beta (17.1.b): The second phase of our development cycle, which may or may not be the middle two months depending on the alpha phase. In this phase, we look for wider testing and stabilisation. Bigger feature additions are still being done in this phase depending on roadmap progress and scope, but removals are kept to a minimum. Beta images may be provided publicly, by no means intended to be complete or flawless. This helps us to gather feedback early on topics that include installation or hardware compatibility.

Release Candidate (17.1.r): The third and last phase of our development cycle, which is carried out in the last month prior to the real release. In this phase, only small reworks and bugfixes are allowed. The translations are being frozen to enable translators to prepare the final release. Several image sets are provided in this phase. Everyone is encouraged to preview and/or run the next version in a production environment to make the actual release transition as smooth as humanly possible.

We are aware that this is nothing new and don't want anyone to think that. In fact, we're using this generally accepted system to provide more transparency for the upcoming version. Also note that these phases are meant as general guidelines and may be subject to change over time.

Questions? Just ask.


Cheers,
Franco

[Solaris17]

Is it possible to update to the RC series from the beta? The update function doesn't seem to pick it up but you can download the images. That is to say are the instructions posted here https://forum.opnsense.org/index.php?topic=917.msg10577#msg10577 safe to perform on BETA builds?

[franco]

Hi Solaris17,

RC1 didn't work because it had no "opnsense-devel" package, but in RC2 the package is there, upgrade is seamless just like the instructions say.


Cheers,
Franco

[TheForumTroll]

I'm sorry if I'm missing something obvious here but I keep getting a update available (OPNsense 22.1.b3) but updating reinstalls OPNsense 22.1.b_141. Is this the same version or what is going on?

Code: [Select]

pkg-static opnsense-devel reinstalled: 22.1.b_141 -> 22.1.b_141

[madj42]

Someone correct me if I'm wrong but I'm think I remember reading that the development version will always offer something to update to.  One question I have though is, is there an easy way to see on GitHub what changes are being offered with the update?

[franco]

22.1.b3 is the version for "all the packages" while 22.1.b_141 is the opnsense-devel version inside it. The updates loop on purpose to ease testing and once proper version tags are added to the community version in 22.1-RC1 this will not happen anymore.


Cheers,
Franco

[bimmerdriver]

It would be great if the change log included a reference to the opnsense version so it would more obvious if it's new. Currently, there is no obvious way to know (at least not obvious to me). Lately, I've inadvertently reinstalled the same version several times.

[franco]

Can you show a screenshot of what you mean? The number should be displayed in the header of the modal.


Cheers,
Franco

[phantomsfbw]

Is Sensi expected to be broken in this developer version in its current state, as in there is a Phalcon error after installing the plugin?  Thanks for any insight.

[franco]

It's not expected but it isn't unlikely since we move the development version to use Phalcon 5 and Zenarmor team may not have updated their code accordingly just yet.


Cheers,
Franco

[bassopt]

Honest question.
Why did you choose FreeBSD 14.1 and not 15?
It seems that pfsense is using version 15 now on their latest plus version and will on their next CE too, wouldn't it make more sense for Opensense to go for verson 15 too, since netgate still contribues with quite a bit of code to mainstrean Freebsd, avvoiding the need of backports.
I'm  probably beeing a complete ignorant on this, but it just makes sense in my head.

[franco]

Disclaimer: I'm aware of https://www.reddit.com/r/PFSENSE/comments/1dixii0/pfsense_ce_280_development/

> Why did you choose FreeBSD 14.1 and not 15?

Because it is the latest supported release of FreeBSD. The counter question is why did pfSense skip all of the latest and greatest releases of FreeBSD 13? Why do they not backport many of their features? I don't see OpenVPN DCO in FreeBSD 13.

We are not FreeBSD developers. We never received commit bits. Sometimes I wonder why we don't meet the criteria, but then I remember who sponsors FreeBSD and ignores our bug reports and patch submissions.

We do have regular patch submissions and features brought to FreeBSD. We contribute to a lot of software fixing build and compatibility issues. We maintain FreeBSD ports and improve the FreeBSD package manager. It's easy to find this information if you want to compile a video where you don't want to mislead people.

Staying within fixed bounds of FreeBSD releases is a good idea. You have less crashes, less problems, less regressions, less noise overall. And that's not supposed to be a good thing?


Cheers,
Franco

[bassopt]

Haha. Thanks for disclaimer.  and the clarifications

I didn’t mean to Insult  your product or anything but my experience with opnsense hadn’t been the best, although I admit probably because I didn’t dedicate as much time to it as I should. ( I’m just a musician of trade and a home laber of passion)
At the time the video you mention made sense to me … but certainly not anymore specially after Mr gonzopancho (lol ) replies and specifically his interactions with me.  ( as of the time of me writing this post  I’m apparently blocked from replying at the subreddit

Keep up the good work. I’ve deleted all my pfsense backups and VMs and restored an old openwrt config until I have time to dig into opnsense in July hopefully when 24.7 is released !    Morally i can’t continue to use pfsense anymore after this.  Free or not.

[franco]

No worries. I just wanted to get a couple of statements on the record WRT FreeBSD.

OpenWrt is certainly a capable option.


Rock on,
Franco

[holunde]

Hi
I don't want to interfere with your discussion, but just mention that I use OPNSense in production at several locations and has been VERY pleased with it for several years.
Not just the software, but also the friendliness I've encountered in my quite few interactions with the company.
I came from PfSense for these systems but got really annoyed because of the way PfSense behaved when they screwed up their WireGuard VPN implementation.
This company does not operate in a way, that I can stand behind. They are close to being complete a**holes, to be frank.
So the budget-money I have for these routers goes to OPNSense.

By the way. I have a CRAZY question for you, Franco:
Have you EVER considered moving the OPNSense-project over to run on top of a Linux-kernel?
Or is this simply too big a change to contemplate at all?
It would cut some ties to this malevolent FreeBSD sponsor, though...
summer greetings from Denmark