In sync would have been nice, but as in sync has been problematic
in the past and I don't expect that to change, I suggest to go with
the last suggestion. I would call it marketing numbers and these
should have another range so that they have clearly differing version
numberings (like the 5.x
On 05/07/2014 10:20 AM, Harald Barth wrote:
In sync would have been nice, but as in sync has been problematic
in the past and I don't expect that to change, I suggest to go with
the last suggestion. I would call it marketing numbers and these
should have another range so that they have clearly
But overall not a major issue for us.
Unfortunately, we have to _guess_ a lot about this, because many of
the issues are probably not issues for the folks here on openafs-info.
Harald.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
On Tue, 6 May 2014 17:04:25 -0500
Andrew Deason adea...@sinenomine.net wrote:
The reason we don't do this now, and the argument for why we should
continue to not do this, is that Windows releases tend to happen much
more frequently than Unix releases (look at 1.6.x vs 1.7.x, though it
One of our main thoughts is that the version numbers should be indicative
of client/server compatibility.
Sent with AquaMail for Android
http://www.aqua-mail.com
On May 6, 2014 6:05:03 PM Andrew Deason adea...@sinenomine.net wrote:
Summary: What version numbers would you like for Windows
On Wed, 7 May 2014, Dave B. wrote:
One of our main thoughts is that the version numbers should be indicative of
client/server compatibility.
clients and servers communicate via the AFS-3 network protocol; new
features (RPCs) are added to that protocol in a backwards-compatible
manner. The
On 5/7/2014 10:44 AM, Benjamin Kaduk wrote:
On Wed, 7 May 2014, Dave B. wrote:
One of our main thoughts is that the version numbers should be
indicative of client/server compatibility.
clients and servers communicate via the AFS-3 network protocol; new
features (RPCs) are added to that
That might be true, however, things like single DES going away (sort of)
as I understand it can break things with older clients.
On Wed, May 07, 2014 at 10:44:21AM -0400, Benjamin Kaduk wrote:
On Wed, 7 May 2014, Dave B. wrote:
One of our main thoughts is that the version numbers should be
On Wednesday 07 May 2014 10:20:59 Harald Barth wrote:
In sync would have been nice, but as in sync has been problematic
in the past and I don't expect that to change, I suggest to go with
the last suggestion. I would call it marketing numbers and these
should have another range so that they
On 5/7/2014 11:04 AM, Dave Botsch wrote:
That might be true, however, things like single DES going away (sort of)
as I understand it can break things with older clients.
DES being turned off in a site's Kerberos realm is not an OpenAFS issue.
That is an organizational policy. The DES
On May 6, 2014 6:05:03 PM Andrew Deason adea...@sinenomine.net wrote:
Summary: What version numbers would you like for Windows and Unix
releases in the future? Some options are described below.
On 7 May 2014, at 10:13, Dave B. wrote:
One of our main thoughts is that the version numbers
On May 7, 2014, at 19:07 , Garance A Drosehn wrote:
On May 6, 2014 6:05:03 PM Andrew Deason adea...@sinenomine.net wrote:
Summary: What version numbers would you like for Windows and Unix
releases in the future? Some options are described below.
On 7 May 2014, at 10:13, Dave B. wrote:
Summary: What version numbers would you like for Windows and Unix
releases in the future? Some options are described below.
Hi everyone,
At EAKC earlier this year, someone asked a question about the different
versioning schemes for Windows and Unix/non-Windows OpenAFS releases.
Specifically, it
13 matches
Mail list logo