[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Naming of new 2.0 release



On Wed, 26 Aug 1998, Steve Lamb wrote:

> On Wed, Aug 26, 1998 at 11:39:34AM -0400, Dale Scheetz wrote:
> > In most cases I would agree with Steve that we should not be involved in
> > the marketing aspects of this product, as that isn't our goal. Let others
> > do this for us, like the CD vendors. In this case, however, I see benefit
> > to users with no lying or misrepresentation, and no reduction in
> > information about which edition of the release is being sold/purchased.
> 
>     Through all this discussion I have asked this one question and have yet
> to get an answer.
> 
>     What happens when joe blow realizes that s/\./r/ and he gets the same
> thing?  Do you change numbering again?  
> 
There is no need. The fundamental change has already been made in the mind
of the vendor. He sees "one" release of 2.0 with however many revisions
that release has, as different than that same number of 2.0 "releases".

One release, over a period of 3 months, with many revisions, is different
than many releases over the same 3 month period. Those who know which
revisions are important to them will ask for them by revision number. They
may then either choose to buy what the vendor has, and obtain the revision
packages elsewhere, or look for a vendor with the revision needed.

When a new customer says, "Do you have the latest release of Debian?", the
vendor can say, "Yes, we have the 2.0 release of Debian.". The vendor
doesn't have to "keep up" with which point release has just been made, or
is about to be made. When it comes time to burn some more stock, the
vendor's tech support gets the latest revision and burns it with fair
chance of selling them.


>     It comes down to hiding and being deceitful without solving anything
> because every few years you end up "revising" how you "represent" a
> "revision."  
> 
>     When they learn, what do you do then?
> 
Sell them what they want. There has never been a suggestion that the
"current" revision scheme should be changed, only that we should continue
to do what we decided to do last release.

I might ask, "How does returning to the old point release method improve
anything?". We already know that it is a problem for someone, even if they
aren't a developer or user, so why make the situation worse?

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


Reply to: