[OpenAFS] OpenAFS and windows/unix versioning

[Stephan Wiesand]

On May 7, 2014, at 19:07 , Garance A Drosehn wrote:

>> On May 6, 2014 6:05:03 PM Andrew Deason <adeason@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 should be
>> indicative of client/server compatibility.
> 
> Unified versions would be best, but I can see where that runs into
> practical difficulties.  The project hasn't had unified versions for
> quite awhile now, and that has not been much of a problem for my site.
> 
> It would be nice to have some scheme which makes it easier to compare
> versions across platforms.  Not quite in the sense of client/server
> compatibility, but in the sense of easily stating what capabilities
> are in the clients which connect to some server.  A cell administrator
> might want to make a decision (or announcement) based on the
> capabilities of "the average client" which connects, for instance.

That didn't work even where we had unified versions. Like Windows clients
give up callbacks during shutdown and hurt outdated servers since 1.3.x
in 2007 but Unix clients will only start doing it now with 1.6.8. So the
1.6.1 Windows client behaves quite differently from the Unix/Linux ones.

> How about always including a 'u' or a 'w' in the major version number?
>  [hrm.  those look too much alike, so maybe use different letters]
> So version 14u.1.2 would be in the releases recommended for unix, and
> 14w.1.2 would be in the releases recommended for windows.  The numbers
> after the 'u' or 'w' would not have to be in lock-step, so '.1.2' in
> one line of releases isn't necessarily related to '.1.2' in the other
> set.  But both lines might jump to a '.2.0' release to signify some
> important change (such as a critical security fix).
> 
> This is just a suggestion, and I don't know if it runs into practical
> issues on some platforms.  I do not feel strongly about changing the
> way versions have been handled.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany