Opened 14 years ago

Closed 14 years ago

#2360 closed task (fixed)

Zsh 4.3.5

Reported by: Ag. Hatzimanikas Owned by: Ag. Hatzimanikas
Priority: normal Milestone: 6.3
Component: BOOK Version: SVN
Severity: normal Keywords: zsh
Cc:

Description

Development version increment.

Release announcement at: http://www.zsh.org/mla/users/2007/msg00331.html

The multibyte support in the development branch is almost complete.

It worths mentioning that all the major distributions excepts fedora (watching their bug reports, they doesn't seem to have *any* interest about zsh) are using the development version.

In a question in zsh workers mailing list (specifically about fedora) the zsh maintainer Peter Stephenson replied with these words.

"What I'm looking for before producing a new stable release (which will probably be version 5) are signs that the multibyte support in 4.3 is complete enough that most users aren't going to find significant gaps. It doesn't have to be flawless. At some point we need to decide that things are working well enough. With Linux, I think that's already the case, but I'm less clear about the state of other systems I don't see."

http://www.zsh.org/mla/workers/2007/msg00471.html

Attachments (1)

zsh-4.3.4.diff (6.1 KB ) - added by Ag. Hatzimanikas 14 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 by Ag. Hatzimanikas, 14 years ago

Owner: changed from blfs-book@… to Ag. Hatzimanikas

comment:2 by Ag. Hatzimanikas, 14 years ago

Status: newassigned

comment:3 by Ag. Hatzimanikas, 14 years ago

Please I need an opinion/decision about this ticket.

The question really it is: Should we update to the development version or not? According with Peter Stephenson and to the most of the Linux distribution maintainers of the package, the 4.3.* branch is considering stable enough. The 4.2 branch is unmaintained from a long time now and all the development happens in the 4.3 branch.

Personally I would like to update to the development version, since it's the only version that works properly in multibyte locales.

If the answer is negative, I will move this ticket to future, unless there will be a stable (5) version in the meantime before the 6.3 Book release. Reading the Zsh mailing list though, I didn't saw a sign that a release it will happen soon enough.

comment:4 by David Van Mosselbeen, 14 years ago

Well, looking to my Debian Etch box (the stable branch), the "zsh" package points to "4.3.2" Sure, this is not a reference at all. But at the same time, if some know stable branches of some distributions have considered this as stable enough... I may suggest to do some researches, and looking what "others" are thinking and doing about this issue.

Right now, the docs mention this multibyte problem. People are still able to take the choice.

So, my concussion: i don't know :-)

by Ag. Hatzimanikas, 14 years ago

Attachment: zsh-4.3.4.diff added

comment:5 by Ag. Hatzimanikas, 14 years ago

Thanks itchi for the input,

Fedora also moved to 4.3.4 in 25 of July with a funny changelog (Move to upstream 4.3.4, the stable non-stable release).

Anyway, attached is a patch for review to update the Book in the 4.3.4 development version.

I removed the warning, I added the --bindir=/bin switch and the libcap as optional dependency, and finally I added the --enable-cap and --enable-pcre switches in the command explanations.

comment:6 by Ag. Hatzimanikas, 14 years ago

Thanks to Paul Ackersviller who backported many bug fixes onto the 4.2 branch, there is out a new release (4.2.7) from the stable branch.

As I said its only a bug fix release with no new functionality, apart from some completion functions.

Here is a part of Paul's message some weeks ago.

" I've finished the back-merging of many bug-fixes onto the 4.2 branch, as well as most completions (the notable exceptions being 22328 and 23479). The ChangeLog on the branch should match the changes committed to the branch, but I wouldn't be surprised by a mistake or two given the hundreds of changes I looked at. I've also sanitized all the branch's .distfiles using Peter's check_dist_files script.

If anyone cares, I also have the list of change numbers I looked at, but didn't merge. These were not all just new features, but some fixes didn't merge cleanly or compile properly, sometimes only because of extra parameters on something like zerr(). I didn't attempt to guess at a resolution for these problems, but left the changes out. "

There is also a series of dev-releases in all the December. Peter Stephenson promised for a release around Xmas. So forget the attached patch for now, as 4.3.5 it will be a major release with many bug fixes and many enhancements.

in reply to:  6 comment:7 by Ag. Hatzimanikas, 14 years ago

Replying to Ag.Hatzim:

There is also a series of dev-releases in all the December. Peter Stephenson promised for a release around Xmas. So forget the attached patch for now, as 4.3.5 it will be a major release with many bug fixes and many enhancements.

At the end, there will be no new release before Christmas, in the meantime here is a dev release for anyone cares about the zsh development.

ftp://ftp.zsh.org/pub/development/zsh-4.3.4-dev-6.tar.gz

Some of its features (long list).

A new module zsh/curses provides the builtin zcurses for access to the curses screen manipulation package; see the entry in the zsh/modules manual. Configuration of terminal libraries is now easier with the --with-term-lib option to configure.

The module system has been extended to add "features" which can be manipulated with zmodload -F. This allows a more convenient and powerful way of manipulating builtins, parameters, mathematical functions and test operators provided by modules. For example,

zmodload -aF zsh/datetime b:strftime p:EPOCHSECONDS

specifies that builtin strftime and parameter EPOCHSECONDS are to be autoloaded from the module zsh/datetime, but that no other features from zsh/datetime will be enabled without being specifically mentioned. In addition, the zsh/stat module can now be loaded with

zmodload -F zsh/stat b:zstat

to make the builtin available under the name "zstat". The alternative name "stat" is still available but commonly clashes with the name of an external binary. The completion system has been modified to use only "zstat".

"zmodload -i" behaviour is now the default, so "zmodload <module>" no longer fails if <module> is already loaded.

The globbing flag (#cN,M) is an extension of the extended globbing # and ## pattern operators, forcing the previous expression to match at least N and no more than M times, similar to {N,M} in regular expressions.

In zsh native mode (NO_KSH_ARRAYS), retrieving array subscript zero returns the empty string or attempting to set subscript zero with arrays is now an error. This was previously a source of difficult to find problems. The old behaviour can be obtained with the KSH_ZERO_SUBSCRIPT option for compatibility, however there is no reason to use this in new shell code and KSH_ARRAYS should be preferred for compatibility with other shells.

Previously, splitting quoted parameters using "${(s.:.)param}" removed empty fields. This is incompatible with the usual effect of quoting parameters. This behaviour has been retained for compatibility, but using an explicit "@" flag as in "${(@s.:.)param}" forces empty fields to be retained.

The sched module has a parameter zsh_scheduled_events that makes querying scheduled events from a function easier.

The calendar function system can now use UIDs imported from other calendar systems to identify entries for replacing. Handling of recurring events is more robust but still limited.

comment:8 by Ag. Hatzimanikas, 14 years ago

Summary: Zsh 4.3.4Zsh 4.3.5

Version increment to 4.3.5

Release announcement at:

http://www.zsh.org/mla/users/2008/msg00144.html

comment:9 by Ag. Hatzimanikas, 14 years ago

I need to know what to do with this issue.

My opinion is to update the package to 4.3.5

If there is no objection I will update zsh probably within next week.

comment:10 by DJ Lucas, 14 years ago

Enough of the various distros are already using it and calling it stable to support the move. The maintainer himself says that it is stable on Linux, but he doesn't know about other OSes, so there will be _no_ _stable_ _release_. That is usually the sign to use know stable development versions. Go for it.

comment:11 by Ag. Hatzimanikas, 14 years ago

Resolution: fixed
Status: assignedclosed

Thanks DJ.

Fixed in r7201.

Note: See TracTickets for help on using tickets.