[OpenAFS] Re: OpenAFS and windows/unix versioning

[Andrew Deason]

On Tue, 6 May 2014 17:04:25 -0500
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.

After the release-team meeting today, there was some discussion on this
in the openafs jabber room. If anyone that was not there would like to
see that discussion, there is a transcript here:
<http://conference.openafs.org/openafs@conference.openafs.org/2014-05-07.html>

I'm not going to provide detailed "minutes" or anything, but I'd like to
at least mention a few things that came up for people to see.

It seems like there was a lot of agreement for having separately-"named"
releases for Windows vs Unix; where the "name" for Windows is just the
existing "OpenAFS for Windows", at least for now. The version number
would maybe be '7', to be an intuitive extension from the existing 1.7
series. (That is, we may have a next release that is 7.31.0 instead of
1.7.31.)

Unix numbering would remain the same, and the next series would be 1.8,
followed by 1.9 or 2.0. There seems to be agreement in not alternating
even/odd for development releases, and just not having development
releases at all. For preparing for a new series like 1.8, instead of
building up via 1.7 "devel" releases, we would just issue a lot of 1.8.0
prereleases (or maybe using 'alpha', 'beta', and 'pre', instead of just
'pre'). If there is demand for "devel" releases outside of prereleases,
we can just use snapshots from git.

We know there are restrictions in OS X packaging for a limited number of
prereleases, but I'm not sure if that matters. Getting the version
correct in the _packaging_ for prereleases may not matter, since in my
mind the idea is that you are installing these manually, and any
automated logic to deal with version numbers appropriately is less
important. So for example, all 1.8.0 prereleases on OS X might be
packaged as effectively 1.8.0pre1, but e.g. 'rxdebug -version' still
prints the real version. Of course, all of this is still subject to
change; it's just an idea.

Also, a few responses to some suggestions from the list that were
discussed:

On Wed, 7 May 2014 09:34:14 -0400
chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> 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.

I agree that this could be useful, and maybe could let client releases
move a little more aggressively while keeping servers more conservative.
But there is some resistance to this because it seems like it would add
extra workload to creating releases. So IMO it sounds desirable and
something that may happen someday, but at the moment the current
"combined" releases aren't painful enough to motivate doing this.

Of course, a "client" release could be unix and windows, so we wouldn't
be adding a "new" release (still two releases: just client/server
instead of unix/windows), but that's still effectively 2 releases for
the "unix people" as things are now. I also get the impression that
people aren't confident enough we'd be able to keep even the Windows
client and Linux client together without needing to fork off again.


On Wed, 7 May 2014 17:16:00 +0200
Markus Koeberl <markus.koeberl@tugraz.at> wrote:

> 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...

This could be done, but one concern is that this makes it difficult to
keep parallel "version series" going at the same time, which is
something we want to do. One idea is to have the date just be one
component of the version, so we'd have something like:

1.2014.05
1.2014.06
1.2014.07

and

2.2014.05
2.2014.06

But I think what I heard is that there may be some restrictions on
getting all packaging to go along with such a scheme. It also looks a
little "weird" to me, especially if we need point releases like:

2.2014.05.1

Of course, the other way is to have the date be first and have
subversions off of that, like 2014.05.1 or "2014.05 update 1", but then
you have dates that are actually misleading, since 2014.05.9 might be
released in the year 2019. So that seems _worse_.

None of these seem like "blocker" issues and are maybe fixable, but I'm
not sure if this is "worth it" to just get the benefit of "I know what
month release X is from just by looking at it".

-- 
Andrew Deason
adeason@sinenomine.net