Is git branch v3.0.x safe to take snapshot from for a long term release?
We're getting ready to freeze our version of freeradius for RHEL-7. Currently RHEL-7 has 3.0.0 as released on October 7. There have been a quite a few bug fixes in the last 3 months which have been committed to the v3.0.x branch. All those fixes should be part of whatever we release as freeradius 3 in RHEL-7. Even though the October 7th release of 3.0.0 is the current official release we don't think we should ship this version in RHEL-7, there have been too many problems in 3.0.0 which have subsequently been discovered and fixed (kudos to the community and the core developers for finding and fixing 3.0.0 issues! Thank You.) What I want to do to prepare the RHEL-7 version is to apply all the git commits between release_3_0_0 tag and HEAD as a patch thus effectively making the RHEL-7 version of 3.0.0 equivalent to the current head of the v3.0.x branch. This is also equivalent to making a snapshot of the v3.0.x branch at a certain moment in time (today). Is there any reason to believe the current state of the v3.0.x branch as of today is not the best state of 3.x to become a long term RPM in RHEL-7? In other words is anyone aware of anything problematic in the v3.0.x tip and why this shouldn't be the final state of 3.0 in the initial release of RHEL-7? P.S.: I realize more fixes will be committed to the v3.0.x branch as time goes by, We've been averaging 4.5 commits per day to v3.0.x since 3.0.0 was released. Missing some future fixes is OK, one has to put a stake in the ground at some point. -- John
John Dennis wrote:
What I want to do to prepare the RHEL-7 version is to apply all the git commits between release_3_0_0 tag and HEAD as a patch thus effectively making the RHEL-7 version of 3.0.0 equivalent to the current head of the v3.0.x branch. This is also equivalent to making a snapshot of the v3.0.x branch at a certain moment in time (today).
OK.
Is there any reason to believe the current state of the v3.0.x branch as of today is not the best state of 3.x to become a long term RPM in RHEL-7? In other words is anyone aware of anything problematic in the v3.0.x tip and why this shouldn't be the final state of 3.0 in the initial release of RHEL-7?
I'm not aware of any issues left in 3.0.x.
P.S.: I realize more fixes will be committed to the v3.0.x branch as time goes by, We've been averaging 4.5 commits per day to v3.0.x since 3.0.0 was released. Missing some future fixes is OK, one has to put a stake in the ground at some point.
Most of the patches are for non-core pieces. e.g. 15 build fixes for WITH / WITHOUT functionality, ~60 for src/tests, ~30 for the build system, etc. The goal is to stabilize future releases, including this one. Alan DeKok.
Is there any reason to believe the current state of the v3.0.x branch as of today is not the best state of 3.x to become a long term RPM in RHEL-7? In other words is anyone aware of anything problematic in the v3.0.x tip and why this shouldn't be the final state of 3.0 in the initial release of RHEL-7?
I'm not aware of any issues left in 3.0.x.
There's the one Stefan reported which should be fixed. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Is there any reason to believe the current state of the v3.0.x branch as of today is not the best state of 3.x to become a long term RPM in RHEL-7? In other words is anyone aware of anything problematic in the v3.0.x tip and why this shouldn't be the final state of 3.0 in the initial release of RHEL-7? I'm not aware of any issues left in 3.0.x. There's the one Stefan reported which should be fixed.
I'll run an --enable-developer build for symbols on Monday (using current branch code) and see if the issue was transient. I'll let you know ASAP. Anway... if the issue is a real problem, you'd probably be able to issue a patch in RHEL in a matter of days, right? An online update is usually the first thing anybody should run after install, so the exact state of the release goldmaster isn't that important. Or is it? Stefan
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Stefan Winter