On Tue, 6 May 2014 17:04:25 -0500 Andrew Deason <[email protected]> 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/[email protected]/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 <[email protected]> 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 <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
