On Wed, Jul 10, 2002 at 08:35:58PM -0700, Paul Johnson wrote:
| On Wed, Jul 10, 2002 at 09:29:22PM -0500, Derrick 'dman' Hudson wrote:
|
| > That doesn't work, though, because sid is NOT debian 4.x. 4.x is a
| > stable release (which hasn't occured yet).
|
| Almost right, except sid's more likely to get numbered 3.1 when it forks
| to testing.
| Where did you get the idea that even major revisions are
| somehow considered stable while others aren't?
I didn't mention the woody/3.x comment because woody _is_ 3.0 (or will
be in the (hopefully near) future when it is released). Calling woody
version 3.0 does make sense. Calling sid X.Y doesn't, though.
| We're not the kernel cabal, we don't have bizarre numbering schemes.
At least the kernel's numbering scheme is consistent and indicates
what it is meant to. It allows people to test not-yet-stable
versions, yet still have a marking point (number) by which to refer to
the set of code they are working with. I think the major difference
there is the kernel is, effectively, autonomous whereas debian assigns
the "bizarre" (or not-so-bizarre) numbers to the components
individually. The end effect is the same -- each "snapshot" has a
unique ordered identifier.
| > IMO debian should not take some steps backwards just to be "familiar
| > with other OS's". Debian should be as advanced as it can be.
|
| I couldn't help but to think back to the original episode of Invader
| Zim,
Sorry, I'm not familiar with that show.
| where one of the tallest says, "It's not stupid, it's advanced!"
:-)
| I agree with what you're saying, though.
To answer Dave's question :
> It's not clear what backward steps are being discussed here.
The backward step would be to close the door and not let you (someone
who is not a Debian Developer) see the unstable and testing dists. If
we only let you see the stable releases then we wouldn't have this
discussion about a "lack" of version numbers. I think allowing the
end-user to join in the development process in whatever way s/he is
able is a more advanced process that is mutually beneficial (users get
new stuff fast, developers get more testers and assistance in
developing).
> Naming releases to be more easily understandable seems like a
> forward step in communicating with users and a step that's
> completely unrelated to how advanced Debian is.
I'll agree here. You (Dave) didn't say that version numbers were
needed, just clear names.
| > | Maybe what I'm reaching for is that Debian needs "marketing names",
| >
| > That sounds good.
|
| NAK. If this were the case, Progeny would have succeeded. Or Stormix.
| Or Corel. Or any other distro that happened during "let's take the best
| distro, slap our own label on it, and ride the success" phase that a lot
| of software companies did to look like they were branching out.
|
| Otherwise, that statement was of the painful variety that I haven't
| heard since I worked in a tech support call center.
The way I understood the suggestion, it wasn't a matter of changing
anything other than the name. What the name actually really doesn't
matter, as long as it conveys the right meaning. The "marketing"
names should be clear(er), to help everyone understand the system.
| > There's a BIG difference here. All those releases you cite are
| > *stable*, *static* (well, except that MS doesn't understand numbering)
| > releases. That equates to the following, in debian
|
| Well, Microsoft's revenue model runs well against version numbering in
| that if they advertised the real version number instead of their
| marketroid names, they'd have a much harder time selling their crap.
Actually what I was referring to was the fact that there are at
_least_
3 major versions of Windows 95
2 major versions of Windows 98
6 major versions of Windows NT 4.0
3 major versions of Windows 2000
and who knows how many minor versions. It the fact that different
combinations of source (which yield different binaries) are labeled
with the same (marketroid) "version".
The really fun part of it all is the programmatic differences in the
various releases. It's even worse than UNIX-land since at least the
various Unix vendors document their APIs. What I've learned about the
differences between windows releases has come across on maililng lists
for projects that involve supporting windows (eg python).
| Oh, goodee. No more security updates even to those who want them
| for a good portion of the Windows user base...
I wonder if a determined person couldn't assemble a complete windows
installation from the security updates. After all, the "update" is
just a new binary that is dropped over the old one (followed by a
reboot). If you could unpack the installer archives and arrange all
the .dlls and .exes together, maybe you'd have enough to legally
obtain an unpurchased copy. _Why_ someone would actually want to do
that is beyond me, but still.
-D
--
The crucible for silver and the furnace for gold,
but the Lord tests the heart.
Proverbs 17:3
http://dman.ddts.net/~dman/
Attachment:
pgp6bw15Rhk6i.pgp
Description: PGP signature