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

Re: Bug#21969: debian-policy: needs clarification about Standards-Version



To stop the big confusion, this is what I wanted to express with the
changelog notice: (Note, that you'll have to check whether you like this
setup--this is just my very personal opinion. Any future policy
manager/editor should probably then update the manuals if there is a
consensus about this.)

 1. The change of the version numbering scheme became necessary since
there are three Debian policy manuals, namely `the Debian Policy Manual',
`the Debian Packaging Manual', and the `Developer's Reference', all of
which have some `official status'. Since a few things overlap in the
manuals and since there is only a single `Standards-Version' field (i.e.,
not `Policy-Standards-Version', `Packaging-Standards-Version', ...) I
thought it would be best to use the same version numbers on all three
manuals. 

  However, a problem in the past has been that any new upload of the
policy-manual package, even if there haven't been any changes to the
manual but perhaps some typos fixed in the libc6-migration paper, etc.,
made people update their `Standards-Version' fields. 

  That's why I thought, there should be a common `Standards-Version' (3
digits, currently 2.4.1) which is shared by the manuals, plus a
patch-level which might be different between the manuals. The patch level
is incremented with each new upload or any bug fixes _which don't
introduce new policy_, i.e., fixed typos, etc. 

  2. In the past, people specified 4 digits in the Standards-Version
field, like `2.3.0.0'.  Since any `patch-level changes' don't introduce a
new policy, I thought it would be better to relax policy and only require
that the first 3 digits are specified. (4 digits can still be used if
someone wants to do so.) 

  3. Current lintian only checks whether the first 3 digits of the
Standards-Version field are `known'. With that, standards-version entries
like 2.3.0.0 and 2.4.1 are all valid, but 2.5.0 is invalid (since this
standard-version doesn't exist yet). This has only one disadvantage: 
someone could specify 2.4.1.99, which doesn't exist by now either, and
lintian would accept this. (If necessary, lintian could be improved, of
course, but then, lintian would have to be updated with each new
policy-patch-level too!--that's the reason why I coded lintian the way
it's now). But this is only a minor problem I think, since patch-levels
aren't really important in the Standards-Version fields.

  4. When introducing this change, I was busy with other policy changes as
well and I didn't want to introduce unnecessary changes to the manuals. 
IIRC, I checked out what was said in the manuals about the
Standards-Version field and thought that no changes are necessary. 
Obviously, I was wrong. If you all agree with my interpretation above,
someone should update the manuals to specify that `only the first 3 digits
of the manuals version represent the Standards-Version, and either these 3
digits or the complete 4 digits can be specified--that's up to the
maintainer'.


I hope this helps to stop the `confusion' about the changelog entry. If
there are still unclear things about what I said, feel free to contact me
again.


Thanks,

Chris

PS: Though, I've decided to leave Debian, that doesn't mean that I'm
completely `offline' now. In case you have other problems interpreting any
of my manuals/texts, feel free to drop me a note (but please do this via
a CC to me, since I don't follow the lists too closely). 

--                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian has a logo!    schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                    
Check out the logo     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
pages at  http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: