Re: Release naming ...
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 22 Aug 1997, Richard G. Roberto wrote:
> A while ago I posted my feelings on this to Debian private,
> but it was _very_ ill received at the time. I'll restate it
> now. Commercial products do not rename their OS every time
> there's a bug fix! I suggested adopting a more commercial
> approach to release naming for the reasons it is now being
> done. I suggested only incrementing the revision number
> (i.e. issuing a point release) when one of three criteria
> were met:
The name of a product, and its version number are two distinct things.
Windows95 is the name of a product; is has (at least) two versions one is
4.000a the other is OSR2 4.000b -- not I'm not familiar with Windows95 and
I might have got this wrong; I'm just trying to use an example to
illustrate here.
> 1) The OS as a whole as been modified significantly, where
> significantly is defined by the nature of a change in
> functionality, as it impacts the user community. This may
> be a bug fix that's fundamental in some way, such as a
> major libc issue.
>
> 2) There is functionality necessarily introduced into the
> release as its needed but can't wait until the next major
> release. The Broadway upgrade qualifies as this, even
> though that wasn't the reason it was done.
>
> 3) There are a (very) large number of _serious_ bug fixes
> against the current release.
>
> Unless one of these criteria is met, the release should
> remain frozen, and un-incremented. Fixes should be
> available (and easily identified) from public ftp servers,
> and that should be that. Vendors are of course welcome to
> sell CDs including the fixes, or even just containing them.
> People who have the current release can then judge what they
> feel they should upgrade based on their needs. Having
> versions like 1.2.17 is very confusing to normal people (=
> people who don't give a rat's ass what OS they're using.)
>
> Its obvious that perspective buyers feel the same way, and
> experienced marketers(sp?) know this. This is why they have made
> these suggestions to us. What Bruce has done is a
> compromise to this. The name will still identify a
> "snapshot" of the stable release relative to a series of
> "fixes" against a major release, it will just do it in a
> less confusing manner.
It is obvious? In that case would you expect such a long thread about it?
Too me, 1.3.1 identifies a snapshot of the system, as does 1.3.2 - the
learning curve is slight and once learnt is used so routinely throughout
the software industry that I wouldn't expect the learning to be a
significant hardship.
> Furthermore, "we" as in "the developers" made a decision to
> organize our leadership into a group of trusted directors,
> and an _elected_ president. In the past, the most
> frustrating thing for me to read was when Bruce posted
> things like "I can't lead where no one will follow" since
> this is the definition of leadership (i.e. we don't need a
> leader to take us where we're already going). Now that
> Bruce is doing as we've asked, we're pissing and moaning
> about it. Come on!
Leadership is not simply proposing your point of view and then assuming
that if nobody follows you you aren't effective. Leadership is about
listening to the people you are leading; canvassing for opinions, and at
the end of day proposing something. Sometimes what you propose what be
well received, in that case a leader ought to be able to outline the
benefits of going through the hardship.
> The fact is, in a few months, nobody is going to care about
> this thread, but we'll all be quite happy about being
> available at EggHead along side of Win98, etc. Bruce
> has done the right thing, and inevitably, change has
> consequence. The pains of this change are small and well
> worth it.
It does not seem like a small change to be (see further on).
> I was one of the first people to question all of this on
> this list because I didn't understand it. Since then, Bruce
> (and others) have explained it in such explicit terms, I
> find it hard to believe that anyone could still be getting
> the wrong idea. The mechanics of how this new scheme will
> be implemented may be a little fuzzy, but so what! I'm sure
> that piece will become clear as it happens. The important
> thing is understanding what's happenning and why. The how
> part will become self evident. My original concern was the
> the integrity of the system was potentially at risk (even if
> not at first, down the road), but its clear this is not the
> case.
This integrity agrument does not seem at all clear. Bruce has posted (so
far) only twice with details of what is happenning; every other post has
been in response to some other person. There was also a post from Manoj
which is similiar to what Bruce has suggested.
So far I have seen two schemes for 1.3:
Scheme 1:
1.3.1 will be renamed 1.3.1 Revision 0 and each change will
increment the right-hand most digit. Thus the next one will be 1.3.1
Revision 1, then 1.3.1 Revision 2.
Scheme 2:
1.3.1 will be renamed 1.3 Revision 1, and each chnage will
increment the right-hand most digit. Thus the next one will be 1.3
Revision 2, then 1.3 Revision 3
In the case of scheme 2; why bother? In the case of Scheme 1 why do you
need an additional change number? /etc/debian_version is 1.3 - what is
wrong with using the '.1' for the revision number?
It has been suggested that this is becasue some CD manufacturers don't
want to try and sell as fast a moving target as Debian. They want slower
numbers. What happens when another manufacturer wants the same? The issue
here is that CD manufacturers have failed to understand, in my opinion,
Debian _current_ version numbering.
You should be informing CD manufacturers that the current version of
Debian is 1.3 - that if they label it any other way, it is not an official
Debian CD. You also suggest that they include some text along the lines of
"As with most software in the computer industry, changes wil
occur. Once you have completed installation of your Debian GNU/Linux
computer system, we recommended that you use the version control tools
provided to apply any updates that might have appeared."
Finally, on the topic of other mailing lists. I have heard debian-devel,
debian-policy and debian-private being bandied about as places where this
sort of discussion is more appropriate. Yet www.debian.org lists only four
mailing lists as open, public and relevant for users. They are
debian-announce, debian-changes (both of which are moderated) and
debian-user and debian-user-digest. If there are better places to discuess
this (and similiar topics) I recommend that the web pages be updated to
reflect that.
Regards,
Anand.
- --
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBM/7Cs2RmcAD8BdppAQERqgQAkJh3CBAQNINR4hMFpQrifyPXTaamMEz+
76dpq/Ht8n8F4sKYJnMHAUTkrMARNT05q2e/Ca6Pduxdb9BzCGjD/kgBupqIDcqw
NEGWkhgXc7oM7YUmWOaD8qi5V84ieZEHvpPSBOdECTiGTDxrizU60VQBGwUVupfS
dyff5KmvToY=
=sZ8w
-----END PGP SIGNATURE-----
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: