-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/12/09 16:01, Carsten Krüger wrote:
> Hello Tyrone,
>
>> Can I ask, as it's 3+ years since the release of 2.0.9, why 2.1
>> does not have an actual stable release, rather than being at rc22?
>
> Everybody asks this question.
> James didn't understand software release life cycle[1] at all!
> OpenVPN is not suitable for business use :-(
Even though, I can agree that it has been a rather odd routine (if it
can be called a routine) for a release cycle, I find it a bit too strong
claiming OpenVPN is not suitable for business use.
Any product which will be used in business settings will need to go some
form of acceptance testing. The testing requirements and expectations
will be different from user to user. Such testing should not be based
on if a product is defined as "stable" from the developers of the
product, rather if it works stable in the setup needed for an acceptance
test.
Some users will then find out that a release candidate works better and
is more stable for them, then what a release defined as "stable" by the
developers.
Having that said, I do agree that the release candidate cycles have been
rather long for OpenVPN. But that *do not* mean that the OpenVPN 2.1
RC22 is unstable for the majority of users. Debian, Ubuntu, Red Hat
Enterprise Linux, Fedora, CentOS provides OpenVPN 2.1 RC candidates as
their stable releases. I believe there are some discussions in Gentoo
to move the RC candidate over to stable. That is the majority of Linux
distributions. Slackware and openSuSE still seems to ship 2.0.9 as the
stable version, afaik.
I have personally run OpenVPN in production from 2.1_rc15 and up to
rc21, without any issues on any of these. And I do know a lot of other
users do something similar.
> On 20 May 2009 he stated:
> We are very close to 2.1. I know there's been some discussion about the
> Windows client GUI, whether it deserves to live in 2.1. We do have a
> new client GUI that we've developed as a part of our Access Server
> product and we are open to releasing it with 2.1, however doing so would
> probably add more RC cycles to the 2.1 release.
>
> The other option is to just release what we have now, pending a week or
> so of testing on rc16, and get the new Windows client GUI into a
> post-2.1 release.
>
>
> After RC16 much new features are included ...
I have gone through the changelog [2] from rc16 up to rc22, and I must
say I'm surprised you say that "much new features are included". There
are a few ones, yes. But to call it many is a bit exaggerating.
Here is an summarized extract of the changelog:
- ----------------------------------------------------------------------
rc16: Windows installer changes, read config file from stdin, management
interface via unix domain sockets, added "nogw" support to
- --server-bridge, "pid" command to the management interface, new
"daemon_start_time" and "daemon_pid" environmental variables, build fixes.
rc17: Changed misc debug levels, fixed race condition in management
interface, increased management interface command buffer size, Windows
build fixes, added "redirect-private" option, added "autolocal" redirect
flag for Windows, increased TLS_CHANNEL_BUF_SIZE, fixed symbol conflicts
in Windows CryptoAPI, fixed bug when 'local' option is used.
rc18: build fix (--enable-small), fixed build problem on Windows
rc19: Windows TAP driver fixes, compat fixes for building with older
autoconf
rc20: Fixed bug with --redirect-gateway option changes from rc17. Fixed
several build and ./configure tweaks (to enable/disable features in
compile time), fixed proper SELinux implementation, improved connection
init performance, made maximum number of "route" definitions
configurable, removed limitation of parameters being pushed to clients,
added --server-poll-timeout option, added AUTH_FAILED reason message to
clients, added client-kill command to management interface, added
- --remote-random-hostname option.
rc21: Hardened session renegotiation
rc22: Fixed Windows bug connected to dhcp-pre-release or dhcp-renew
options where used in combination with route-gateway dhcp. Changed from
warning to failure if more that 16 certificates were found in the
certificate chain.
- ----------------------------------------------------------------------
- From this list, there is quite few new features which touches the VPN
and networking part (--server-bridge nogw, --redirect-private and
"autolocal", push route amount configurable, --remote-random-hostname).
It's been some more new features connected to the management interface,
which after all is a brand new feature in OpenVPN 2.1 (pid, AUTH_FAILED
reason message, client-kill).
The rest is basically build and bug fixes, mostly on the Windows
platform. In addition, there's been done some improvements connected to
compile time configurations, which basically enables and disables
features and improvements connected to performance and security.
I honestly struggle to see "much new features" here. Yes, there are
many changes, but not many features. But I do see that some of these
new features which has been introduced mostly is connected to the
OpenVPN Access Server product James is also working on. Except for
that, the rest is usually things which is normally found during a test
period. And instead of releasing a 2.1 premature, which will would
require several fixes shortly afterwords, a longer RC period has been
preferred.
If the 2.1_rc16 release would be the final 2.1 version, we would by now
(in about 5 months) have reaced 2.1.6. Does that sounds like a good
candidate for final release? On the other hand, rc15 was living for
about 6 months before rc16 came, which probably was a really strong
candidate for a final 2.1 release. Until the issues found between rc16
and rc22 surfaced. I trust and believe James tries to reach a stage
where the RC candidate will be as solid as rc15 once was.
There has to be reasons why James is reluctant to finalise the 2.1
release. I just wish the process of that decision would be much more
transparent to the community. Maybe then, the community would
understand the situation better, or could maybe even help out better
with solving the last unsolved issues.
Anyway, in all projects it is important to draw a line and just say
"this is the final version". And I do hope we are here soon now with
OpenVPN. But a premature release which leads to a lot of quick patch
releases will only harm the quite good reputation OpenVPN do have, when
it comes to stability.
kind regards,
David Sommerseth
[2]
<http://www.openvpn.net/index.php/open-source/documentation/change-log/71-21-change-log.html>
> [1] https://secure.wikimedia.org/wikipedia/en/wiki/Software_release_life_cycle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAksamowACgkQDC186MBRfrq7cgCglBww4M1sT+l4YeZQnkVsMRFa
cTQAniXV0h0BqMoxRyzbbCqRP7/Juo/5
=Bxwf
-----END PGP SIGNATURE-----
|