[OpenAFS] OpenAFS and windows/unix versioning

[Dave B.]

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 <adeason@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:
>
> 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
> adeason@sinenomine.net
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info