Why is 1.10, 1.11 not considered?
Alain
Jim Hall escreveu:
> Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
> naming. I'd rather we reserve those numbers for bug-fix releases that
> don't add any new functionality.
>
> For standard distributions, I prefer we use the s
that should probably
very, very minorunless of course there is a MAJOR rewrite that I am not
aware of...like when MS-DOS introduced file handles in 2.0
- Original Message -
From: "Jim Hall" <[EMAIL PROTECTED]>
To:
Sent: Thursday, November 02, 2006 4:20 PM
Subject: Re
L PROTECTED]>
To:
Sent: Thursday, November 02, 2006 3:44 PM
Subject: Re: [Freedos-devel] Update proposal
> May I suggest two decimal cyphers? (1.01, 1.02, 1.03... 1.99)
> 9 small updates to FreeDOS 1.0 may not make FreeDOS 2.0.
>
> Aitor
>
> 2006/10/29, Jim Hall <[EMAIL PR
"Arkady V.Belousov" wrote:
> 1. To eliminate confusing (both human DD/MM-MM/DD and machine sorting,
>better place year before).
There is no "human confusion", because I wrote "MMM" (three "M"), e.g.,
"03-NOV-2006".
"Machine sorting" doesn't apply here, because I didn't talk about
filenames.
Hi!
3-Ноя-2006 10:07 [EMAIL PROTECTED] (Robert Riebisch) wrote to
freedos-devel@lists.sourceforge.net:
>> Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
>> naming. I'd rather we reserve those numbers for bug-fix releases that
>> don't add any new functionality.
RR> I dis
Jim Hall wrote:
> Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
> naming. I'd rather we reserve those numbers for bug-fix releases that
> don't add any new functionality.
I dislike such debates so much, that I use DD-MMM- for all my
projects. ;-)
Robert Riebisch
--
> EA> That is a pity. Did Blair comment about the FreeCOM patches? Did
>
> Ask Blair yourself, for me he is too rare answers.
Some of us work 12 hours/day.
--
Fall is my favorite season in Los Angeles, watching the birds change
color and fall from the trees.
David Letterman (1947 - )
Se
Hi!
2-Ноя-2006 15:20 [EMAIL PROTECTED] (Jim Hall) wrote to
freedos-devel@lists.sourceforge.net:
JH> Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
JH> naming.
Yes. And for me, second looks more sensible, because allows explicitly
differ intermediate releases (1.0 ==
Yes, "1.3.2" makes perfect sense, I think. First, "1.3" indicates the
third minor release after "1.0". Now let's say there was a really bad
bug discovered in FreeCOM 0.99B in that distro, found just after going
live with "1.3", so we'd make a bug-fix distro right away as "1.3.1"
that included
It looks good, but I just wonder how to name the second bug-fix
release after the third release after FreeDOS 1.0, in that case you
are forced to something like 1.3.2...
Aitor
2006/11/2, Jim Hall <[EMAIL PROTECTED]>:
> Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
> nami
Using 2-digit subversions ("1.01") looks too similar to "1.0.1" kind of
naming. I'd rather we reserve those numbers for bug-fix releases that
don't add any new functionality.
For standard distributions, I prefer we use the simpler 1-digit
subversions. In my mind, if we make 9 small updates af
Hi,
2006/10/30, Eric Auer <[EMAIL PROTECTED]>:
>
> Hi Jim,
>
> > E! I'd rather not go back to "beta9 SP2" etc naming scheme...
>
> Right. I have a related question: Tom gave me a copy of his
> 2035-Tom kernel sources, and I included a 2037-findfirst fix
> in the 2036 kernel. I might find some
May I suggest two decimal cyphers? (1.01, 1.02, 1.03... 1.99)
9 small updates to FreeDOS 1.0 may not make FreeDOS 2.0.
Aitor
2006/10/29, Jim Hall <[EMAIL PROTECTED]>:
> E! I'd rather not go back to "beta9 SP2" etc naming scheme. The
> next FreeDOS should _not_ be a "FreeDOS 1.0 SP1". The n
Hi!
2-Ноя-2006 15:45 [EMAIL PROTECTED] (Eric Auer) wrote to "Arkady
V.Belousov" <[EMAIL PROTECTED]>:
>> No! There should be present somewhere stable, no-more-changed edition,
>> which should used as "absolute point". I think, with releasing FreeDOS 1.0,
>> which uses 2036, 2036 should be froz
Hi!
2-Ноя-2006 15:09 [EMAIL PROTECTED] (Eric Auer) wrote to "Arkady
V.Belousov" <[EMAIL PROTECTED]>:
>> http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/kernel2036-binary.zip
>> http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/kernel2036-source.zip
EA> Correct - when I update
Hi!
2-Ноя-2006 12:14 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
>> This is what stops me currently from dealing with kernel, because there
>> is no management centralization. Eric, do you support/control your kernel
>> edition? What about Kenneth' edition? Who con
Eric Auer escreveu:
> Agreed. Once we reach 1.9 we should just call the next version
> the 2.0 one :-). Please have a look at
IMHO after 1.9 comes 1.10.
I also don't like jumps in version numbers like Firefox did. It makes
people very confused. I have seen it in Mozilla's user list.
And, I thi
Hi Eric,
IIRC 2037 fixed somthing in LFN, I vote for that in a new version.
Has Blair givven you info about 2037 changes?
Alain
Eric Auer escreveu:
> Hi Jim,
>
>> E! I'd rather not go back to "beta9 SP2" etc naming scheme...
>
> Right. I have a related question: Tom gave me a copy of hi
Hi Jim,
> E! I'd rather not go back to "beta9 SP2" etc naming scheme...
Right. I have a related question: Tom gave me a copy of his
2035-Tom kernel sources, and I included a 2037-findfirst fix
in the 2036 kernel. I might find some more useful fixes in
2035-Tom and 2037, and then I guess "20
installs FreeDOS 1.1. The patch is an even
smaller download than the base CD to make the systems equal.
-T
- Original Message -
From: "Jim Hall" <[EMAIL PROTECTED]>
To:
Sent: Sunday, October 29, 2006 1:10 PM
Subject: Re: [Freedos-devel] Update proposal
> E! I&#
E! I'd rather not go back to "beta9 SP2" etc naming scheme. The
next FreeDOS should _not_ be a "FreeDOS 1.0 SP1". The next FreeDOS is
indeed an incremental improvement with no major changes (i.e. updated
packages, etc) then "FreeDOS 1.1" would be acceptable. A larger jump in
functionali
Well, to be like our more refined OS counterpart (MacOS), there was
typically a 3-6 month update cycle (the longest I remember was 9
months)...hence the 7.5, 7.5.1, 7.5.2, 7.5.3, etc
Or, we could go the Microsoft route...issue a big patch file that updates
and fixes based using a patch prog
22 matches
Mail list logo
