[OpenAFS] Re: OpenAFS and windows/unix versioning

[Stephan Wiesand]

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:
>=20
>> Summary: What version numbers would you like for Windows and Unix
>> releases in the future? Some options are described below.
>=20
> 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.h=
tml>
>=20
> 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.
>=20
> 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.)
>=20
> 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.
>=20
> 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.

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.
>=20
> Also, a few responses to some suggestions from the list that were
> discussed:
>=20
> On Wed, 7 May 2014 09:34:14 -0400
> chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:
>=20
>> 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.
>>=20
>> This would let the Unix client versions move ahead a little faster.
>=20
> 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.
>=20
> 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.
>=20
>=20
> On Wed, 7 May 2014 17:16:00 +0200
> Markus Koeberl <markus.koeberl@tugraz.at> wrote:
>=20
>> 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 ;-)
>>=20
>> 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...
>=20
> 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:
>=20
> 1.2014.05
> 1.2014.06
> 1.2014.07
>=20
> and
>=20
> 2.2014.05
> 2.2014.06
>=20
> 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:
>=20
> 2.2014.05.1
>=20
> 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_.
>=20
> 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".

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany