Release notes

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/