--qcHopEYAB45HaUaB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 24, 2007 at 11:38:11AM -0500, Przemys??aw Pawe??czyk wrote:
> On Sat, 24 Mar 2007 16:24:08 +0100
> Jan Danielsson <jan.m.danielsson@gmail.com> wrote:
>=20
> Thanks! I'm happy! As far as the diagrams are concerned. ;-)
>=20
> One excerpt of Orewellian newspeak (from the text):

How is that Orwellian (note Orwell has only one "e" in it)?=20

> "The maintenance branch(es) can be considered an __easy way__ (my
> emphasis) to get the most up to date fixes for a given release.

They are. Once you think in terms of how other people use the releases.

The whole point of all of the releases is to offer users varying degrees=20
of inovation and stability.

The idea is that when you put a system into production, you use the latest=
=20
release. Right now, that's 3.1. 4.0 is in beta, and you can use that if=20
you want (I probably would, but then again I don't run high-profile=20
servers).

As an example, though, let's say you put the server into production when=20
3.0 was the latest release.

There have been a number of fixes to the 3.0 code base. Some have been=20
security fixes, and some have been low-risk features. There are a stream=20
of releases based on 3.0, namely 3.0.1 and 3.0.2 (assuming I'm remembering=
=20
numbers correctly). These releases are 3.0 with only important security=20
fixes. Nothing else. The idea is that these releases are VERY similar to=20
3.0, and as such updating to them should be a low-risk action.

Sometimes, however, you want to leave a system in production but want a=20
few new features. The 3.1 family of releases have more features than 3.0,=
=20
yet are mostly the same. New drivers and new subsystems will have been=20
added, along with the security fixes that went into the 3.0.X updates.

4.0 is in beta. It's not yet ready for production, but is much more stable=
=20
than current.

> There are daily updated snapshots of the latest maintenance branches, ava=
ilable via both CVS, FTP and SUP. The directories pub/NetBSD/NetBSD-release=
-3-0/ and pub/NetBSD/NetBSD-release-2-0/ contain the extracted sources plus=
 weekly updated tar files of both the 3.0 and 2.0 release branches respecti=
vely. These files are created in a similar manner to those in the /pub/NetB=
SD/NetBSD-current directory."
>=20
> I decided to partitioned my HDD to have two partitions for stable and tes=
ting releases. So I dived into ftp to find out ISO files. The more I went d=
own or read the more the mess made my hair stand up on end. "This set" here=
, "that set" there, ISO STABLE here, ISO BETA/UNSTABLE/5.0 (???) there, and=
 no ISO for 4.0.
>=20
> BTW. Is the ISO for 4.0_BETA or 5.0_preBETA (from http://iso.aydogan.net/=
)?
> NetBSD-i386-4.99.16-install.iso    24-Mar-2007 04:14  233M
>=20
> I think we deserve some help from NetBSD developers. Let there be a page =
from where I can choose appropriate ISO for testing.
>=20
> 1) NetBSD 3.1
> 2) NetBSD 3.1.1 (aka bla, bla, bla)
> 2) NetBSD 4.0_BETA2 (aka 3.99.yyyy)
> 3) NetBSD 5.0 (aka 4.99.xxxx)

No. 4.0_BETA2 is NOT 3.99.yyy. Nor is 4.99.xxx 5.0. 5.0 doesn't exist yet.

> And the hell with the 4.99.xxx, 3.99.yyy etc. For developers the major
> or minor designations are of great value helping them keep the releases
> tidy and in consistant way. For the users they create hurdles, more,
> they are thorns in the a**.

Well, we've gone over the numbering before, and most other users have come=
=20
to understand the system. We've also discussed the system, and this is the=
=20
result of many discussions and changes.

The problem we have is what do we number -current between releases.=20
NetBSD-current right now is neither 4.0 nor 5.0. It isn't 4.0 because=20
we've made radical changes to the kernel since 4.0. It's also not 5.0=20
because we haven't decided what 5.0 will be, and we're confident that=20
there are features which we haven't yet added that will be in 5.0.

So we are using 4.99.XXXX numbers right now. I doubt there will be a 4.9=20
release, much less anything near 4.99. So the numbers we are using for a=20
release are very separate from other 4.X numbers. Likewise they are all=20
less than 5.0.

We were using 3.99.XXX before we cut the 4.0 branch. When 4.0 was branched=
=20
off of -current, current moved to 4.99.XX. Likewise, when 5.0 is branched,=
=20
current will move to 5.99.XXX.

Take care,

Bill

--qcHopEYAB45HaUaB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGCsq3Wz+3JHUci9cRAoHxAJ9ro+Lxenx49f1n4wvJG8QC4yv2AQCeIywd
6VCtg4za2OrQ9OzsQm0SXcQ=
=VVv1
-----END PGP SIGNATURE-----

--qcHopEYAB45HaUaB--