[OpenAFS] Re: OpenAFS and windows/unix versioning

Stephan Wiesand stephan.wiesand@desy.de
Wed, 7 May 2014 19:28:30 +0200

On May 7, 2014, at 19:03 , Andrew Deason wrote:

> 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 =
> in the openafs jabber room. If anyone that was not there would like to
> see that discussion, there is a transcript here:
> =
> I'm not going to provide detailed "minutes" or anything, but I'd like =
> at least mention a few things that came up for people to see.
> It seems like there was a lot of agreement for having =
> 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 =
> 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 =
> prereleases (or maybe using 'alpha', 'beta', and 'pre', instead of =
> 'pre'). If there is demand for "devel" releases outside of =
> we can just use snapshots from git.
> We know there are restrictions in OS X packaging for a limited number =
> 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.

The "internal" version of prereleases on OS X is something like 1.6.8fc2 =
for 1.6.8pre2, and up to 3 digits are allowed for the "final candidate" =
numbering. So, no issue.

> 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 =
>> a server release you affect potentially thousands of people.  If you
>> screw up a client release, you only affect those that installed it =
>> 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 =
> But there is some resistance to this because it seems like it would =
> 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 =
> 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 =
>> 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 =
> 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 =
> 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".

Stephan Wiesand
Platanenenallee 6
15738 Zeuthen, Germany