From David Korn, as referenced by Garrett, forwarded by Roland. > I expect that the new features are subject to change > based on feedback (bugs and ideas). Once there has > been enough feedback that I feel comfortable I remove the - > suffix. That sounds like a resounding "yes" - new features can be altered in the "t-" to "t" transition.
(BTW: I wouldn't expect it to be any other way. We make the same allowance for Beta releases. We just shouldn't be placing components with Beta [non-]guarantees in potentially FCS products.) - jek3 Roland Mainz wrote: > Joseph Kowalski wrote: > >> Garrett D'Amore wrote: >> >>> I've seen mail from David Korn (not CC'd to PSARC, unfortunately) >>> which I think cleared this up unambiguously. Check the "no" box, and >>> lets move forward. :-) >>> >> Can we forward this to PSARC (actually the case, so it is captured)? >> >> Then we can truly move forward.... >> > > I've attached his email to this one... > > ---- > > Bye, > Roland > > > > ------------------------------------------------------------------------ > > Subject: > Re: [ksh93-integration-discuss] 2008/344 [ksh93 Integration Update 1 > Amendments 1] > From: > David Korn <dgk at research.att.com> > Date: > Thu, 29 May 2008 17:17:01 -0400 > To: > ksh93-integration-discuss at opensolaris.org > > To: > ksh93-integration-discuss at opensolaris.org > > > jek3 at sun.com > Subject: Re: Re: [ksh93-integration-discuss] 2008/344 [ksh93 Integration > Update 1 Amendments 1] > -------- > > I thought that I would provide information on two of the issues > that have been bantered about on this list for the last week > or so. > > 1. What is the meaning of - and + for a release. > I try to make major code changes at the beginning > of a letter change. For example, the type system > as added to the 't' release and this includes the new > enum builtin. While the ksh93t- release passes all > the ksh93s+ regression tests (plus a few new tests), > I expect that the new features are subject to change > based on feedback (bugs and ideas). Once there has > been enough feedback that I feel comfortable I remove the - > suffix. At this point I will only fix bugs that are either > critical or those that are minor and I deem to be safe to fix. > Releases subsequent to release without a suffix use a +. > More major code changes will have to wait for the next major release. > A major release (a new letter) typically occurs about once > a year. > > 2. The namespace issue. > The key to handling the namespace issue is with the PATH > and FPATH variables. ksh is able to load and add both > builtins and functions based on the PATH search. > Whenever a name that is not currently known by the shell > is found, it does a PATH search looking for executables > and functions found on PATH. For directories that are > also in FPATH, the file will be loaded (dotted) and then > a command of that name is run. > This, if you want enum to be out of the default namespace, > you could create a shared library with the enum code, > and put a script named enum in a directory named by FPATH > that contains > built -f enum.so > where enum.so contains the enum built-in code. > > I recommend not using full pathnames in the code or special > characters in the name to avoid collisions. > > David Korn > dgk at research.att.com > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080529/2cbbce6b/attachment.html>
