[OpenAFS] OpenAFS and windows/unix versioning

[Andrew Deason]

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