On May 7, 2014, at 19:03 , Andrew Deason wrote:
> On Tue, 6 May 2014 17:04:25 -0500
> Andrew Deason <adea...@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/open...@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.
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 <c...@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.koeb...@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".
--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
