Re: [OpenAFS] OpenAFS and windows/unix versioning
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 example from Andrew). Or call the Windows versions 14.x this year and 15.x next year. Then we will never reach the feared OfW-13 version for sure ;-) Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 differing version numberings (like the 5.x example from Andrew). Or call the Windows versions 14.x this year and 15.x next year. Then we will never reach the feared OfW-13 version for sure ;-) Would agree with the reasoning. The only real drawback from the current versioning is that the major version numbers are close enough together to imply that the UNIX version is somehow old or stuck on a legacy branch (compare to the similar-sounding 1.4 series that just got de-supported).. not exactly the impression we'd like to convey. Of course, you could just wait until the Windows client has pulled ahead far enough on its own, but perhaps a single version bump would be good enough. But overall not a major issue for us. Cheers, jan ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 shouldn't always be quite that bad). The reasons for this I believe are that the Windows client sometimes needs to make drastic changes quickly due to changes imposed by Microsoft in Windows itself or other components. This can happen on other platforms, too, but what I've been told is that this a much bigger issue on Windows than anywhere else. In extreme cases this may affect non-Windows parts of the code, and so the stability of Unix releases could be affected even though Unix releases gain none of the benefits. Since the Windows release is really just the client (AFAIK) I don't see any reason to keep it in lock step with the Unix releases. This leads to the next logical step that perhaps the servers and clients could be released separately on Unix as well. If you screw up a server release you affect potentially thousands of people. If you screw up a client release, you only affect those that installed it and the fix is easy enough. This would let the Unix client versions move ahead a little faster. Personally, versions are just numbers. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 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 was asked when the version numbers were finally going to converge again. That question was not really answered with consensus at the time, and various OpenAFS developers have still not all agreed on if the version numbers should ever converge. In addition, most discussions on this topic so far have just involved developers, but there might be users or administrators with strong opinions on this that are not getting heard. So, I am raising this topic on -info to ask users and administrators to voice their opinions on what they would like to see. This isn't a tally of votes or anything; I personally just want to see what people tend to like, what sounds awful, etc. While there are technical details and potential debates and such that are relevant here, I'm trying to keep this at a level of discussing what users/administrators see; what branding people want. Actually working out the details if implementing any system is a matter for -devel or the release team or the gatekeepers, etc, and not for this list. Anyway, I'm going to outline some possible approaches as I understand them, so people can see what we're dealing with. Anyone feel free to correct me if I've misrepresented a position: - Unified versions Of course, the most intuitive system would just be to have Unix and Windows releases from the exact same version. That is, eventually we have a 1.8.0 on Unix and Windows, and a 1.8.1 on Unix and Windows, etc etc. 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 shouldn't always be quite that bad). The reasons for this I believe are that the Windows client sometimes needs to make drastic changes quickly due to changes imposed by Microsoft in Windows itself or other components. This can happen on other platforms, too, but what I've been told is that this a much bigger issue on Windows than anywhere else. In extreme cases this may affect non-Windows parts of the code, and so the stability of Unix releases could be affected even though Unix releases gain none of the benefits. I do not pay enough attention to Windows to _know_ how unfixable/intrinsic this is, but I believe that's the reasoning. Creating releases for the non-Windows platforms also tends to be a little slower because that involves more platforms, and we need to coordinate more people and build more binaries. So, following this approach may result (frequently) in a situation where a new release needs to be created with Windows-specific changes, but there are no changes ready to be included in the non-Windows part of the code. We'd then either have Windows-only versions in the middle of the stable release series, or we'd have versions where the Windows releases are different from the previous version, but for all Unix platforms the the releases are effectively identical. That may be confusing. Example: 1.8.0 on Unix and Windows 1.8.1 on Windows (Unix unchanged) 1.8.2 on Windows (Unix unchanged) 1.8.3 on Unix and Windows 1.8.4 on Windows (Unix unchanged) You might wonder why we don't create e.g. a 1.8.3.1 release for just Windows. Historically in OpenAFS, 'nano' point releases are just for adding platform support or other minor issues. That is, there is no need to upgrade to 1.8.3.1 if you're already running 1.8.3. Creating a Windows-only 1.8.3.1 would not follow this pattern (unless it was just for platform support). - The existing system Right now, we effectively have Unix releases as 1.6.x versions, and Windows releases as 1.7.x versions. We could continue doing something like this, with the next Unix versions being 1.8.x, and the next Windows versions as 1.9.x. Or Windows on 1.8.x, Unix on 1.9.x, or Unix on 1.10.x, whatever. The point is, under this system Unix and Windows are on separate branches of minor x.y versioning schemes, and their micro x.y.z releases are completely detached from each other. The problem with this approach is that some people find this confusing and I believe have been complaining about it. A user may see version 1.7.13, and chooses it over 1.6.7 because it looks newer. Or they assume that any odd-numbered minor version (x.y.z where y is odd) is less stable and avoid it, since historically any odd-numbered minor version series were indeed development releases. Example: 1.8.0 on Windows 1.9.0 on Unix, and then:
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 expectation is that any client version should function usefully against any server version; I don't see there being such compatibility concerns. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 protocol in a backwards-compatible manner. The expectation is that any client version should function usefully against any server version; I don't see there being such compatibility concerns. It is not only an expectation but a requirement. All OpenAFS releases must be backwards compatible with not only all OpenAFS Servers but all IBM AFS 3.6.x Servers as well. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 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 expectation is that any client version should function usefully against any server version; I don't see there being such compatibility concerns. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- David William Botsch Programmer/Analyst @CNFComputing bot...@cnf.cornell.edu ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 have clearly differing version
numberings (like the 5.x example from Andrew). Or call the Windows
versions 14.x this year and 15.x next year. Then we will never reach
the feared OfW-13 version for sure ;-)
It could even be ${year}.${month}. So it is very easy to guess how old the
client is. In our environment we do not have an automatic installation system
for windows (only two hosts and a few laptops which I see every few years)
Once I already searched the release announcements to find out how old it is...
Markus
--
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 functionality has not been removed from OpenAFS distributions. For that matter, none of the client side kaserver support has been removed either, nor will it be for many years. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] OpenAFS and windows/unix versioning
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 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. 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. -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS and windows/unix versioning
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: 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS and windows/unix versioning
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 was asked when the version numbers were finally going to converge again. That question was not really answered with consensus at the time, and various OpenAFS developers have still not all agreed on if the version numbers should ever converge. In addition, most discussions on this topic so far have just involved developers, but there might be users or administrators with strong opinions on this that are not getting heard. So, I am raising this topic on -info to ask users and administrators to voice their opinions on what they would like to see. This isn't a tally of votes or anything; I personally just want to see what people tend to like, what sounds awful, etc. While there are technical details and potential debates and such that are relevant here, I'm trying to keep this at a level of discussing what users/administrators see; what branding people want. Actually working out the details if implementing any system is a matter for -devel or the release team or the gatekeepers, etc, and not for this list. Anyway, I'm going to outline some possible approaches as I understand them, so people can see what we're dealing with. Anyone feel free to correct me if I've misrepresented a position: - Unified versions Of course, the most intuitive system would just be to have Unix and Windows releases from the exact same version. That is, eventually we have a 1.8.0 on Unix and Windows, and a 1.8.1 on Unix and Windows, etc etc. 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 shouldn't always be quite that bad). The reasons for this I believe are that the Windows client sometimes needs to make drastic changes quickly due to changes imposed by Microsoft in Windows itself or other components. This can happen on other platforms, too, but what I've been told is that this a much bigger issue on Windows than anywhere else. In extreme cases this may affect non-Windows parts of the code, and so the stability of Unix releases could be affected even though Unix releases gain none of the benefits. I do not pay enough attention to Windows to _know_ how unfixable/intrinsic this is, but I believe that's the reasoning. Creating releases for the non-Windows platforms also tends to be a little slower because that involves more platforms, and we need to coordinate more people and build more binaries. So, following this approach may result (frequently) in a situation where a new release needs to be created with Windows-specific changes, but there are no changes ready to be included in the non-Windows part of the code. We'd then either have Windows-only versions in the middle of the stable release series, or we'd have versions where the Windows releases are different from the previous version, but for all Unix platforms the the releases are effectively identical. That may be confusing. Example: 1.8.0 on Unix and Windows 1.8.1 on Windows (Unix unchanged) 1.8.2 on Windows (Unix unchanged) 1.8.3 on Unix and Windows 1.8.4 on Windows (Unix unchanged) You might wonder why we don't create e.g. a 1.8.3.1 release for just Windows. Historically in OpenAFS, 'nano' point releases are just for adding platform support or other minor issues. That is, there is no need to upgrade to 1.8.3.1 if you're already running 1.8.3. Creating a Windows-only 1.8.3.1 would not follow this pattern (unless it was just for platform support). - The existing system Right now, we effectively have Unix releases as 1.6.x versions, and Windows releases as 1.7.x versions. We could continue doing something like this, with the next Unix versions being 1.8.x, and the next Windows versions as 1.9.x. Or Windows on 1.8.x, Unix on 1.9.x, or Unix on 1.10.x, whatever. The point is, under this system Unix and Windows are on separate branches of minor x.y versioning schemes, and their micro x.y.z releases are completely detached from each other. The problem with this approach is that some people find this confusing and I believe have been complaining about it. A user may see version 1.7.13, and chooses it over 1.6.7 because it looks newer. Or they assume that any odd-numbered minor version (x.y.z where y is odd) is less stable and avoid it, since historically any odd-numbered minor version series were indeed development releases. Example: 1.8.0 on Windows 1.9.0 on Unix, and then: 1.8.1 on Windows 1.9.1 on Unix or 1.8.0 on Windows (stable) 1.9.0 on Windows (devel) 1.10.0 on Unix (stable) 1.11.0 on Unix (devel) - Different release names Many other software projects also treat Windows as a somewhat special case. One
