Re: Package naming vs. versioning

[Grant Bowman <grantbow@svpal.org>]

Thank you Julian for that complete summary.  I can't think of any other
questions or scenarios to ask about.

Regards,

--
-- Grant Bowman                                   <grantbow@svpal.org>



* Julian Gilbey <J.D.Gilbey@qmul.ac.uk> [011128 16:06]:
> (1) libdb: Shared library packages have the major version number in
>     their name; see policy 11.3.
> 
> (2) Epochs are designed for when a mistake is made or the version
>     numbering scheme changes.  Remember that epochs are often not
>     shown with the version number, so use them only when essential.
> 
> (3) Kernel example: yes, you are right.
> 
> (4) autoconf2.13/autoconf and other examples, such as fvwm1/fvwm: this
>     is only done in cases where the newer package differs so
>     significantly from the older package that the maintainer believes
>     that there is a real need for the old package to continue to
>     exist.  In this case, the newer package usually supersedes the old
>     one, but the old one continues to be available if specifically
>     wanted.
> 
> (5) apache (1.3)/apache2, in the past fvwm (1.x)/fvwm2.  Here are
>     examples where the newer package is still in alpha or beta state
>     and not yet ready to be released into the wild.  In this case, we
>     don't want people to be automatically upgraded, and so we name the
>     unstable package something different, so people only get the newer
>     package if they specifically request it.  At a later stage, when
>     the newer version is more stable, they may rename the newer one to
>     the original name and provide a dummy transition package for
>     "brave" people.