The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

Re: version number changes



Bruce Perens writes:
> It seems the marketing problem with frequent point releases is not so much
> that we update the CD or the FTP archive, it's that we change the version
> number of the system. Perhaps we should not change the version number, and
> just put a date on the CD or something that would indicate when it was
> taken from the FTP archive. This would mean we could issue updates
> regularly, and issue updated CDs when appropriate, but keep the version
> number the same. For example, the X package change is something we did for
> Richard Stallman, but isn't the least bit important to the end-user and
> doesn't really warrant a version number change.
> 
> I agree this is all pretty silly.

It is rediculous.  Even if this really is a marketing problem I don't
think we should take that much respect to it.  We should meet
somewhere in the middle.

IMHO bumbing the version number's last digit is ok if there are
different packages.  Telling the user not to worry about 1.3.0 or
1.3.12 is not a good idea, too.  I believe we should think about
something between.

a) Trying to keep one release the same as long as possible.
   . Important changes like the introduction of XFree86 3.3 instead of
     3.2, of course, is a good reason for an increased version.

b) If I get a new minor number (1.3.2 instead of 1.3.1) every
   week or two at least I get the impression that this piece of
   software is
   . quite unstable or
   . in a heavy development state
   and therefore cannot be used on machines which have to run stable
   and without any change for months.

   This was the case with mutt.  I planed to package it before Ray did
   this, but every four days there was a new release.  So I gave up.
   It is impossible to keep track of the development.  One has to run
   some tests so that nothing is broken between releases &c.

c) I'd love to have one "mostly stable" release and a bunch of
   updates.  If we have some severe changes or updates then bump a new
   minor release number, for sure.  But mostly the updates should be
   located in one updates directory.

   Doing so it is only few effort for users to upgrade.  They really
   see where the differences are.  And they see a _stable_ release.
   This is the most important thing on this.

   The big disadvantage is that we'll have one 400MB directory
   containing the release and a 200MB directory containing the
   updates.  I don't know how to get over this.

   I know there is a ChangeLog in bo but who reads it?  Does users
   look at that file to know what has changed?  I don't know.  From
   now on *I* will look at it, just saw it some days ago.

d) Just using a date instead of release number is reduculous.  It
   still would produce the same problems.

e) Independent of what will be done in the future we have to tell the
   user what's the secret of updates and release numbers.  They should
   worry if they install 1.3.1 and 1.3.12 is the most recent release.
   But they should not worry that much that they skip it or frighten.

   We have to point out what's all about with updates and how they can
   include the updates.  We, too, have to mention that the release is
   still stable and an increase of the minor number only comes from
   small changes.

   Users should watch the ChangeLog file to find out if they should do
   an upgrade.  We should also encourage users to subscribe to
   debian-announce to get informed about major changes and new
   releases.

Just my $0.02

	Joey

-- 
  / Martin Schulze  *  Debian Linux Maintainer  *  joey@debian.org/
 / http://www.debian.org/              http://home.pages.de/~joey/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .