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 approach that some others take is to create what looks like a slightly different project name or distribution specifically for Windows. The example I think of in my head when I think about this is MIT Kerberos's "Kerberos for Windows" (KfW), but some others do this, too (like "Strawberry Perl", though that seems like just a build for Windows using their existing numbering). Something like that could be done for OpenAFS. In this approach, the Windows OpenAFS releases could be either based on Unix releases (sometimes with additional patches), or be on their own branch as in the existing system. Either way, the Unix and Windows releases would have different names and completely unrelated version numbers, so they would be easily differentiated from each other. I'm not sure if this is actually less confusing for users; having two different names with unrelated versioning schemes maybe looks strange to some people. Some confusion will definitely arise when the two "projects" collide in their version numbers, but that can be less of an issue depending on what numbers are chosen. Examples: OpenAFS 1.8.0 on Unix "OpenAFS for Windows" 5.0 on Windows (based on 1.8.0) "OpenAFS for Windows" 5.1 on Windows (based on 1.8.0) OpenAFS 1.8.1 on Unix "OpenAFS for Windows" 5.2 on Windows (based on 1.8.1) - Something else Honestly I haven't thought about this too much; I'm just trying to write down the posibilities I've heard discussed so far. It's possible I've missed some other obvious approaches, so feel free to mention something else. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info