On Wed, Apr 04, 2018 at 11:47:09AM -0700, Sean Whitton wrote:
> > §3.2.2 Uniqueness of version numbers
> >
> > The part of the version number after the epoch must not be reused for
> > a version of the package with different contents once the package has
> > been accepted into the archive, even if
On Wed, 04 Apr 2018 at 11:47:09 -0700, Sean Whitton wrote:
> > §3.2.2 Uniqueness of version numbers
> >
> > The part of the version number after the epoch must not be reused for
> > a version of the package with different contents once the package has
> > been accepted into the archive, even if the
Hello,
Thank you for the feedback, Simon.
I tried to incorporate what you said while avoiding talking about the
namespace pairs, for the sake of readability. Further, I shortened
"upstream version without the epoch" to "upstream version" because the
epoch is a Debian thing.
Seeking seconds:
>
On Thu, 29 Mar 2018 at 08:12:15 -0700, Sean Whitton wrote:
> Seeking seconds:
>
> > §3.2.2 Uniqueness of version numbers
This has lost the part of Adam's wording where he explicitly said that
this applies to all three of these namespaces:
* (source package name, source version without epoch)
* (
On Thu, Mar 29, 2018 at 08:12:15AM -0700, Sean Whitton wrote:
> Seeking seconds:
>
> > §3.2.2 Uniqueness of version numbers
> >
> > The part of the version number after the epoch must not be reused for
> > a version of the package with different contents once the package has
> > been accepted into
Hello,
Seeking seconds:
> §3.2.2 Uniqueness of version numbers
>
> The part of the version number after the epoch must not be reused for
> a version of the package with different contents once the package has
> been accepted into the archive, even if the version of the package
> previously using
On Thu, Mar 29, 2018 at 08:02:48AM -0300, David Bremner wrote:
> Adam Borowski writes:
> >
> > Sounds better than mine. I'd re-add "once that package has been accepted
> > into the archive", to make it obvious that resubmissions to NEW and/or
> > mentors are expected to reuse version numbers of w
Adam Borowski writes:
>
> Sounds better than mine. I'd re-add "once that package has been accepted
> into the archive", to make it obvious that resubmissions to NEW and/or
> mentors are expected to reuse version numbers of what they amend.
Personally, I usually increase version numbers in those
On Wed, Mar 28, 2018 at 03:32:02PM -0700, Sean Whitton wrote:
> Suggested replacement:
>
> The part of the version number after the epoch must not be reused for a
> version of the package with different contents, even if the version
> of the package previously using that part of the ve
Hello Adam,
On Wed, Mar 28 2018, Adam Borowski wrote:
> Here's my proposed wording:
Thank you for working on this.
> .
> §3.2.2. Versions must be unique
"Uniqueness of version numbers" would be more fitting with Policy's
tone.
And versions are unique by definition :) It's version numbers
Control: tags -1 +patch
Here's my proposed wording:
.
§3.2.2. Versions must be unique
Because of a quirk of file naming, version numbers that are identical save
for epoch cause problems, and thus must not be used. In such case you may
bump the Debian revision (it doesn't need to start at 1
11 matches
Mail list logo
