Subject: Re: Versioning?
To: None <email@example.com, firstname.lastname@example.org>
From: Ross Harvey <email@example.com>
Date: 12/07/1998 16:26:39
> From: firstname.lastname@example.org (Trouble Free RecepPFFFFFFFFFFFFFFFF)
> Just curious. I mean, what are the criteria for bumping the minor version
> up as opposed to bumping / adding a branch ID?
> We're currently at 1.3I [at least I am]; is this effectively 1.3.3 or
> is it 1.3.2++?
Actually, 1.4 (or 2.0, for that matter) would be a future fork of -current
into a new -current and a new release branch.
That's a completely different animal: 1.3 and all 1.3.x point releases are
based on a fork of -current about one year ago that produced the 1.3 release
branch from the -current of a year ago.
So, going from 1.3I -> 1.3.3 is actually a big step backwards, from the
current development branch to a release branch that hasn't been current
for a year. Now, lots of things have been pulled up from -current to the
release, but they are almost exclusively bug fixes and security patches.
(NetBSD takes security very seriously.) There are exceptions, e.g. some
externally maintained subsystems have had been pulled up as a unit, putting
both bug fixes and new features into the release branch. Presumably, the
external subsystem has already passed its own release engineering procedure.
Change is the enemy of reliability.
Since you can't have the latest features and ongoing development and at
the same time have a high expectation of stability and reliability, we
offer a choice: run the release or run -current. When a new release is
made, the fork is recent, but as time goes on (1.3.1, 1.3.2, 1.3.3) the
release gets further from the latest snazzy features and changes, but
presumably gets closer to a bug-free, stable, and reliable version. The
bigger the gap, the more relatively reliability you might expect from the
release, but the more new features you are doing without.