Version number, release cycle, ports updates discussion

[franco]

Hi guys,

as mentioned on Twitter earlier today we were thinking about the version number system we have come up with over the course the past 5 months and what to do with them after 15.7 comes out. Here are the nuts and bolts:

o Up until now, 15.1 till 15.1.11.4 have been snapshot releases of varying scope. Some have said the version is too long. To leave any taste out of this, let's just say the version string is long. We are aware.
o "15.1" describes the major with year (two digits) and month of the release. Our releases are planned for January (1) and July (7), but they may shift as we go into 2016.
o "15.1.x" describes the minor version, which means the FreeBSD base system and kernel have received upgrades.
o "15.1.1.x" describes the bugfix version, which happened due to QA rejecting a release, larger ports updates or sometimes very tiny GUI hotfixes that needed immediate attention.

What will be changed:

o 16.1 and 15.7 series will part ways very early on, with 16.1 receiving larger batches of changes and 15.7 receiving only bugfixes.

What could be changed:

o Merging the minor version and bugfix version, so that version strings will never extend beyond 15.1.x. It would make certain jumps look larger or smaller, but maybe it doesn't matter in the grand scheme of things with a good firmware update procedure in place like we have.
o The frequency of ports updates could be increased to daily snapshot mode that may come without an associated OPNsense version bump when triggering an update (this is more in the likes of FreeBSD)
o The target frequency for updates was every week and that worked out ok, except when there was nothing to release or two releases happened in the same week. Was this enough, or too much? Should it be faster? There are ups and down to all of the possibilities.

Remember: nothing is set in stone.


Cheers,
Franco

[weust]

In my opinion, minor is minor. So for example 15.7.x or 16.1.x is enough.

[chol]

Thank you, Franco, you have presented very reasonable suggestions and your questions are very thoughtful.

Let me react:

*PRO:

Some have said the version is too long. To leave any taste out of this, let's just say the version string is long. We are aware.

I agree, for the name-strings are not recognizable on the download pages any more, because they are displayed shortened, leaving a redundant list of OPNsense_OpenSSL_..... one under another. The crucial things to differentiate, like platform(i386,amd64), target (vga,nano,serial) should be shown first, in other words, I would opt for a reverse naming convention of our current "name-strings", if they have to stay long.

o 16.1 and 15.7 series will part ways very early on, with 16.1 receiving larger batches of changes and 15.7 receiving only bugfixes.
(..)
o Merging the minor version and bugfix version, so that version strings will never extend beyond 15.1.x. It would make certain jumps look larger or smaller, but maybe it doesn't matter in the grand scheme of things with a good firmware update procedure in place like we have.

Full ACK! That is what I really look forward to see.


*UNSURE:

o The frequency of ports updates could be increased to daily snapshot mode that may come without an associated OPNsense version bump when triggering an update (this is more in the likes of FreeBSD)

Does this imply full port updates or just security updates/fixes in relation to our ports? Could this be labeled "stable" in any association? If not I highly recommend the option for the user, to stay kernel and ports conservative and only security fixes daily (default) or to override this and stay hot-edge for the user's appliance!

o The target frequency for updates was every week and that worked out ok, except when there was nothing to release or two releases happened in the same week. Was this enough, or too much? Should it be faster? There are ups and down to all of the possibilities.

In my oppinion it is o.k. becuase we have an early OPNsense development! But for the future, I would look on this from the perspective of needed * reboots *. Taking the versed user into account, the reboots should be limited - and never come close to a weekly, or even more frequent habit. You may implement a transparent automated or mediated remote update feature (for the family/living community/club with 2 or more OPNsense appliances and just one 'IT guy', or the SOHO business/office  (payed for, remote from netherlands or whatever, as a service).

=* inflexible Automated (standardized) vs flexible User triggered (highly customized) Update-Paths*=
Maybe security updates and upgrades should by default be applied transparent and automatically from our OPNsense servers - even across major FREEBSD versions (-10.1 11.0) if this would be possible.

Moreover for advanced security, we should have a kind of port-pattern cloaking-schematic: by means of random ports for services (documented on console and logs/GUI) or port knocking - to make the surely growing numbers of OPNsense appliances not recognizable by automated cracker's port sweeps.

Remember: nothing is set in stone.

For me this is (another) proof of the OPNsense way, and this is our motto: "Open (source) makes Sense"


*SUGGESTIONS:

(..) we were thinking about the version number system we have come up with over the course the past 5 months and what to do with them after 15.7 comes out.

This comes with a tail: the names and directories of download servers may also have to be planned, as we seem to progress into a more stable 15.7, a development 16.1 and also have experimental versions, e.g. LibreSSL (as of now, this might change/merge I am aware) and HardenedBSD images. This needs to have thoughtful structure, which would not change all too often, too.  I noticed updates to the OPNsense.org download site, with 2 notable things: the mirrors are up-to-date, that is nice, and the sourceforge download-link is missing, why - surely there are reasons for this?! Will the server location(s) and its structure of diverse downloadable versions need help from an additional person (now, in the future) that will take care?

"15.1" describes the major with year (two digits) and month of the release. Our releases are planned for January (1) and July (7), but they may shift as we go into 2016.

Please, let's have an announcement protocol for this, too, not just for the downloadable images, you developers are mostly concerned with. For me, it would be nice to have infos in advance and not find out and reverse docomentation I have just edited and researched, but were out-dated behind the scenes, already. This is frustrating. If this means more work, by all means I would not like to load it on other shoulders but would offer help on this, too, but it should have an agreed uppon structure, better a "protocol" (like etiquette) , that would make cooperation besides developer meetings and "hollandian round tables" (  I really mean it nicely, guys - just to clarify my point ). But obviously these are just my opinion and may not be practical.

[Supermule]

Updates ran super smooth here and no issues what so ever.

Cudos to the dev's! 

[weust]

Updates ran super smooth here and no issues what so ever.

Cudos to the dev's! 

Wrong topic ;-)

[Supermule]

Well message got through me thinks