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

Re: Debian Policy 4.0.0.0



Antonio Terceiro <terceiro@debian.org> writes:
> On Sun, Apr 30, 2017 at 05:50:13PM -0700, Russ Allbery wrote:

>> I think Debian Policy 4.0.0.0 is ready for release.

> One thing I was always curious about: is there a reason to use such a
> deep versioning scheme?

> A shorter version number would make package maintainers life a bit
> easier when keeping Standards-Version: up to date. For example noticing
> 4.0 vs 4.1 is way easier than noticing 3.9.7.0 vs 3.9.8.0.

A couple of people have asked about this.  I think where I'm at is that,
if we could go back in time, I'd use semvar with only three versions.  But
the semantics of the Policy version number is baked into enough stuff that
the minor clarity gain isn't really worth it.

Having the last number of Policy reserved for non-normative changes that
don't create a new Standards-Version for packages is very valuable, so
we'd always want to keep that.  So basically, as you mentioned above, we'd
go to two versions for Standards-Version instead of three.  Basically,
what we'd drop is the distinction between "minor changes" and "moderate
changes," and probably be a bit more willing to bump the most significant
version number when merging some major bit of new policy.

I think that would be totally fine, and somewhat superior to what we have
now.  But to get there we'd have to change the Policy text about the
version, change Lintian to understand the new numbers, change the other
bits on the package tracker that understand Policy version numbers, and
there are probably lots of other bits of software that would need minor
changes (automated tools that maintainers use to update things, for
instance).  This is all doable, but since the gain seems fairly minor, I'm
dubious it's worth asking people to go make all of those changes.

> Another nice to have would be having the major version number matching
> the target Debian release.

This I'm not sure is a great idea mostly because Policy doesn't really
care about the target Debian release, in the sense that we almost never
make some sort of change that's targeted at a specific release.  That just
generally isn't how Debian works, or how Policy works, right now.  It's
far more likely that the change that first rolls out in some Debian
release will finally get properly documented in Policy a full release (or
more) later.

I can definitely imagine a world in which this would make sense to do, but
it would be a world in which we're managing Policy far more proactively
than we currently are (and had the resources to do that).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: