Release notes

phil.davis

The code is all either from the FreeBSD base system - source all freely available to look at online, or in the various GitHub repos under pfsense. The build is triggered at intervals, and will run due to any change - so I expect if you were to look through the repos you will find something that changed (maybe stuff in ports?) and the builder noticed that and did its thing.

The pfsense GitHub is managed by ESF and it is their people who have the write access to make changes. People can freely make pull requests, but they are reviewed before being committed. All code changes are in public view, so anyone can review them and point out any security or other issues.

As others have said, the Beta snapshot builds are just that - builds for testing. There are not updated release notes with every build potentially every few hours. Formal release notes are done when an official release is made.

dcol

Ok then I will ignore the updates until an official release is done. How do I know which build is the 'Official' one? Is the build number posted somewhere as to which is the Official release? Also, when I see an entry in the redmine 'Resolved/Closed' list, how do I know which release that change pertains to? You all make it sound like I am not 'getting it' but where are the build numbers? I have very carefully read all the github and redmine lists but I have no idea what build or release they apply to. It really is not that clear. Then when I see a change that I want to try, how do I get that release, or which release is it? See my point, I hope.

dcol

Ok, I guess I am making this way more complicated then it needs to be, or no one is understanding my question.

It all boils down to this question for me.
If I see a Resolved/Closed item in Redmine, does that mean the current build will reflect that change?
That means I can wait until I see an issue is resolved that affects me, then update.

Also, it slightly bothers me that no one addressed my security concerns. Almost like no one has a clue. That is concerning.

doktornotor

What security concerns? All the stuff is on GitHub. WTF. There is no secrecy, people simply do not have time to write your release notes for testing builds not intended for production use. You can perhaps hire someone who's gonna do the legwork for you, follow github 24/7 and write you the relnotes.

:o ::)

dcol

Your response puzzles me as sarcastic as it was.

So I guess there is no way to tell what fix or feature goes with what. Pretty unprofessional if you ask me.

doktornotor


$ cat /etc/version.{buildtime,lastcommit}
Fri Dec 02 19:20:25 CST 2016
26be03d73c1e358441ec89ad1e5e4f95d05fdef1

There. Everything up to that commit is there. Now, move and look it up @GitHub/Redmine.

(I'd rather not get into the "unprofessional" debate, since it'd get unprofessional pretty fast, you're starting to piss me off. We need coding/bugfixing and not nightly build changelogs.)

Jailer

Stop…...feeding.......trolz.........

dcol

ok, let me ask it again.

If I see a Resolved/Closed item in Redmine, does that mean the current build will reflect that change?

Seems I hit a nerve with doktornotor. Let me explain and justify my comments. Unless PFsense is meant as a consumer game, there needs to be some accountability in a business environment. I have placed PFsense Netgate Enterprise products in many businesses that expect a certain level of security. Many of which are financial or medical related and are mandated by government rules to provide such. I only use current stable releases on those systems and test the dev builds on my own test systems. This is why the security issue is important and should be for any commercial application.

heper

@dcol:

If I see a Resolved/Closed item in Redmine, does that mean the current build will reflect that change?

IF code is modified that is related to a resolved/closed ticket, then that is picked up, the NEXT time the automated builder runs.

@dcol:

Seems I hit a nerve with doktornotor.

no you haven't … you are on the right path to reach the nerve endings

@dcol:

Enterprise products in many businesses that expect a certain level of security. Many of which are financial or medical related and are mandated by government rules to provide such. I only use current stable releases on those systems and test the dev builds on my own test systems. This is why the security issue is important and should be for any commercial application.

documenting experimental builds does not increase security in ANY way.

Release notes are only there to provide an overview of closed/opened bugs and/or new features. They don't provide security.

dcol

Thanks. That answers the builds question.

My concern for security was based on who's allowed to make code changes, not anything to do with the dev version.

phil.davis

Redmine issues have a "Target version" field. While an issue is awaiting resolution, that is the future version that it is hoped the issue will be resolved in. Once the issue is resolved, the Target Version is set to the actual version that the issue [is|will be] released in.

For example, issues resolved recently have Target Version set to 2.4 - because they will be in the next official release, which will be called 2.4.

2.4 is currently in BETA. The particular snapsht build that an issue resolution appears in is not recorded in Redmine. That is because the snapshot builds are not intended for production use, unless you have a particular need for some fix/feature and also have the in-house resources and know-how to track what is happening in real-time on GitHub, understand the code, do your own testing, make an informed decision about what build to install, and be willing to resolve unexpected stuff.

Formal releases are announced on the blog, and in the Forum (up in the top forum section) and on various social media. Those are typically made every 3 to 6 months (it depends on the need for urgent security patches,…). Those are what is recommended for production, and those have a full set of release notes.

Guest

@dcol:

Thanks. That answers the builds question.

My concern for security was based on who's allowed to make code changes, not anything to do with the dev version.

Any PR's are first examined and discussed, only then is the PR accepted and pulled. It would not be possible for some unknown security issue to sneak in to the core. I submit a few PR's and mine usually get held up because of format errors! So it is not easy to just get anything accepted.

dcol

Good to know, thanks

Zargoth3

More info…

https://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/committing.html

Here is where the commits to FreeBSD are listed:

https://freshbsd.org/