Re: Stable release of mc-4.7.0.3
On Sat, 2010-02-27 at 00:20 +0100, Oswald Buddenhagen wrote: Other than that, it's a matter of subjective preferences, I guess. yes, one can also prefer a versioning scheme which converges towards the value of pi. this isn't necessarily sane or even useful, though. Actually, I've just realized that this is not such a bad idea. TeX uses it quite successfully up to these days. Might be that your post actually *was* an allusion to TeX though and I'm playing a slowpoke... -- Sincerely yours, Yury V. Zaytsev ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Stable release of mc-4.7.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, all. Download page: http://www.midnight-commander.org/downloads Major changes since 4.7.0.2. Core * Reorganization of source tree structure (#2037) * Added 'menuinactive' skin item to draw inactive visible main menu (#1999) Misc * Documentation updates * Translation updates Fixes * Missing includes (#2017) * Memory leaks (#2028, #2053, #2058) * Incorrect start up with some special paths (#1992) * MC crashes at exit due to race conditions of destroying subshell and file manager (#2008) * Ctrl-\ key closes the NCurses-based MC (#1926) * verbose option is always switched on after MC start (#1940) * Selections are not visible on monochrome terminals in NCurses-based MC (#1972) * Extra quoting of shell variables in user menu (#1967) * Editor's search parameters are not retained across editing session (#1572) * EditColumnMark can't go up through newline (#1998) * Missed \s symbol in Syntax file (#2010) * ViewContinueSearch segfault on empty search (#1996) * Potencial security risk in mcserv (#1902) * The lslR VFS doesn't work with ls-lR files created in en_US.UTF-8 locale and with files and directories started with whitespaces (#1921) * Contents of RAR archives with filenames that contain / \d\d:\d\d / are not listed correctly (#2029) * FTPFS: strcpy() is used for overlaping strings (#2018) - -- WBR, dev-team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLh8DKb3oGR6aVLpoRAnHVAJ9CZYY8ox3LMLY9N6aCr4DKNtsezwCeJLjZ xAkSVWHOnA0jg757E6XWSWY= =wCkY -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stable release of mc-4.7.0.3
On Fri, Feb 26, 2010 at 02:38:34PM +0200, Slava Zanko wrote: Major changes since 4.7.0.2. why on earth are you again inflating the version namespace? this looks like a rather regular bugfix release, i.e. 4.7.1. and the what you called 4.7.1 is pretty much a 4.8. a.b.c.d releases are only justified if the release tar balls are messed up somehow or some other kind of release showstopper slipped through. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stable release of mc-4.7.0.3
On Fri, 2010-02-26 at 15:27 +0100, Oswald Buddenhagen wrote: why on earth are you again inflating the version namespace? this looks like a rather regular bugfix release, i.e. 4.7.1. and the what you called 4.7.1 is pretty much a 4.8. a.b.c.d releases are only justified if the release tar balls are messed up somehow or some other kind of release showstopper slipped through. I was asked to answer you that what they had in mind in the [epoch].[major].[minor].[release] scheme, 4.7.1.x being maintenance releases and 4.7.x.0 = 4.7.x being feature releases. Also, they say that Redhat uses the same versioning scheme for the kernels they support. Other than that, it's a matter of subjective preferences, I guess. My personal opinion: I don't care as long as there's a scheme to which they actually stick to. -- Sincerely yours, Yury V. Zaytsev ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Stable release of mc-4.7.0.3
On Fri, Feb 26, 2010 at 03:42:47PM +0100, Yury V. Zaytsev wrote: I was asked to answer you that what they had in mind in the [epoch].[major].[minor].[release] that's pretty much a guarantee that the epoch will never change. Also, they say that Redhat uses the same versioning scheme for the kernels they support. the linux kernel's versioning scheme is an expression of a two-level generational development model. you may have noticed that this was dropped years ago - the major version is fixed at 2.6. and you never had such a model in the first place, and you'll never have. so why would you introduce such a scheme? Other than that, it's a matter of subjective preferences, I guess. yes, one can also prefer a versioning scheme which converges towards the value of pi. this isn't necessarily sane or even useful, though. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
