View | Details | Raw Unified | Return to bug 34967
Collapse All | Expand All

(-)doc/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml (-16 / +16 lines)
Lines 30-36 Link Here
30
    <para>The semantics of this are as follows:</para>
30
    <para>The semantics of this are as follows:</para>
31
    
31
    
32
    <para>The maintainer owns and is responsible for that code.  This means
32
    <para>The maintainer owns and is responsible for that code.  This means
33
      that he is responsible for fixing bugs and answer problem reports
33
      that he is responsible for fixing bugs and answering problem reports
34
      pertaining to that piece of the code, and in the case of contributed
34
      pertaining to that piece of the code, and in the case of contributed
35
      software, for tracking new versions, as appropriate.</para>
35
      software, for tracking new versions, as appropriate.</para>
36
36
Lines 100-106 Link Here
100
      not applicable for FreeBSD can be removed.  In the case of Tcl, the
100
      not applicable for FreeBSD can be removed.  In the case of Tcl, the
101
      <filename>mac</filename>, <filename>win</filename> and
101
      <filename>mac</filename>, <filename>win</filename> and
102
      <filename>compat</filename> subdirectories were eliminated before the
102
      <filename>compat</filename> subdirectories were eliminated before the
103
      import</para>
103
      import.</para>
104
104
105
    <para><filename>src/lib/libtcl</filename> contains only a "bmake style"
105
    <para><filename>src/lib/libtcl</filename> contains only a "bmake style"
106
      <filename>Makefile</filename> that uses the standard
106
      <filename>Makefile</filename> that uses the standard
Lines 118-124 Link Here
118
118
119
    <para>The important thing here is that the
119
    <para>The important thing here is that the
120
      <filename>src/contrib/tcl</filename> directory is created according to
120
      <filename>src/contrib/tcl</filename> directory is created according to
121
      the rules: It is supposed to contain the sources as distributed (on a
121
      the rules: it is supposed to contain the sources as distributed (on a
122
      proper CVS vendor-branch and without RCS keyword expansion) with as few
122
      proper CVS vendor-branch and without RCS keyword expansion) with as few
123
      FreeBSD-specific changes as possible.  The 'easy-import' tool on
123
      FreeBSD-specific changes as possible.  The 'easy-import' tool on
124
      freefall will assist in doing the import, but if there are any doubts on
124
      freefall will assist in doing the import, but if there are any doubts on
Lines 131-137 Link Here
131
      vendor branches, it is required that <quote>official</quote> patches from
131
      vendor branches, it is required that <quote>official</quote> patches from
132
      the vendor be applied to the original distributed sources and the result
132
      the vendor be applied to the original distributed sources and the result
133
      re-imported onto the vendor branch again.  Official patches should never
133
      re-imported onto the vendor branch again.  Official patches should never
134
      be patched into the FreeBSD checked out version and "committed", as this
134
      be patched into the FreeBSD checked out version and <quote>committed</quote>, as this
135
      destroys the vendor branch coherency and makes importing future versions
135
      destroys the vendor branch coherency and makes importing future versions
136
      rather difficult as there will be conflicts.</para>
136
      rather difficult as there will be conflicts.</para>
137
137
Lines 152-162 Link Here
152
152
153
    <para>In the <filename>src/contrib/tcl</filename> level directory, a file
153
    <para>In the <filename>src/contrib/tcl</filename> level directory, a file
154
      called <filename>FREEBSD-upgrade</filename> should be added and it
154
      called <filename>FREEBSD-upgrade</filename> should be added and it
155
      should states things like:</para>
155
      should state things like:</para>
156
    
156
    
157
    <itemizedlist>
157
    <itemizedlist>
158
      <listitem>
158
      <listitem>
159
	<para>Which files have been left out</para>
159
	<para>Which files have been left out.</para>
160
      </listitem>
160
      </listitem>
161
      
161
      
162
      <listitem>
162
      <listitem>
Lines 165-171 Link Here
165
      </listitem>
165
      </listitem>
166
      
166
      
167
      <listitem>
167
      <listitem>
168
	<para>Where to send patches back to the original authors</para>
168
	<para>Where to send patches back to the original authors.</para>
169
      </listitem>
169
      </listitem>
170
      
170
      
171
      <listitem>
171
      <listitem>
Lines 270-276 Link Here
270
      </listitem>
270
      </listitem>
271
271
272
      <listitem>
272
      <listitem>
273
        <para>Kernel files;</para>
273
        <para>Kernel files:</para>
274
274
275
        <orderedlist>
275
        <orderedlist>
276
          <listitem>
276
          <listitem>
Lines 294-300 Link Here
294
      </listitem>
294
      </listitem>
295
295
296
      <listitem>
296
      <listitem>
297
        <para>User-land files;</para>
297
        <para>User-land files:</para>
298
298
299
        <orderedlist>
299
        <orderedlist>
300
          <listitem>
300
          <listitem>
Lines 343-359 Link Here
343
    
343
    
344
    <para>For instance, added functions and bugfixes result in the minor
344
    <para>For instance, added functions and bugfixes result in the minor
345
      version number being bumped, while deleted functions, changed function
345
      version number being bumped, while deleted functions, changed function
346
      call syntax etc.  will force the major version number to change.</para>
346
      call syntax, etc.  will force the major version number to change.</para>
347
    
347
    
348
    <para>Stick to version numbers of the form major.minor
348
    <para>Stick to version numbers of the form major.minor
349
      (<replaceable>x</replaceable>.<replaceable>y</replaceable>).  Our a.out
349
      (<replaceable>x</replaceable>.<replaceable>y</replaceable>).  Our a.out
350
      dynamic linker does not handle version numbers of the form
350
      dynamic linker does not handle version numbers of the form
351
      <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
351
      <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
352
      well.  Any version number after the <replaceable>y</replaceable>
352
      well.  Any version number after the <replaceable>y</replaceable>
353
      (ie. the third digit) is totally ignored when comparing shared lib
353
      (i.e. the third digit) is totally ignored when comparing shared lib
354
      version numbers to decide which library to link with.  Given two shared
354
      version numbers to decide which library to link with.  Given two shared
355
      libraries that differ only in the <quote>micro</quote> revision,
355
      libraries that differ only in the <quote>micro</quote> revision,
356
      <command>ld.so</command> will link with the higher one. Ie: if you link
356
      <command>ld.so</command> will link with the higher one. i.e.: if you link
357
      with <filename>libfoo.so.3.3.3</filename>, the linker only records
357
      with <filename>libfoo.so.3.3.3</filename>, the linker only records
358
      <literal>3.3</literal> in the headers, and will link with anything
358
      <literal>3.3</literal> in the headers, and will link with anything
359
      starting with
359
      starting with
Lines 363-369 Link Here
363
    
363
    
364
    <note>
364
    <note>
365
      <para><command>ld.so</command> will always use the highest
365
      <para><command>ld.so</command> will always use the highest
366
	<quote>minor</quote> revision.  Ie: it will use
366
	<quote>minor</quote> revision.  i.e.: it will use
367
	<filename>libc.so.2.2</filename> in preference to
367
	<filename>libc.so.2.2</filename> in preference to
368
	<filename>libc.so.2.0</filename>, even if the program was initially
368
	<filename>libc.so.2.0</filename>, even if the program was initially
369
	linked with <filename>libc.so.2.0</filename>.</para>
369
	linked with <filename>libc.so.2.0</filename>.</para>
Lines 371-383 Link Here
371
371
372
    <para>In addition, our ELF dynamic linker does not handle minor version
372
    <para>In addition, our ELF dynamic linker does not handle minor version
373
    numbers at all.  However, one should still specify a major and minor
373
    numbers at all.  However, one should still specify a major and minor
374
    version number as our <filename>Makefile</filename>s "do the right thing"
374
    version number as our <filename>Makefile</filename>s <quote>do the right
375
    based on the type of system.</para>
375
    thing</quote> based on the type of system.</para>
376
    
376
    
377
    <para>For non-port libraries, it is also our policy to change the shared
377
    <para>For non-port libraries, it is also our policy to change the shared
378
      library version number only once between releases.  In addition, it is
378
      library version number only once between releases.  In addition, it is
379
      our policy to change the major shared library version number only once
379
      our policy to change the major shared library version number only once
380
      between major OS releases.  Ie: X.0 to (X+1).0.  When you make a
380
      between major OS releases.  i.e.: X.0 to (X+1).0.  When you make a
381
      change to a system library that requires the version number to be
381
      change to a system library that requires the version number to be
382
      bumped, check the <filename>Makefile</filename>'s commit logs. It is the
382
      bumped, check the <filename>Makefile</filename>'s commit logs. It is the
383
      responsibility of the committer to ensure that the first such change
383
      responsibility of the committer to ensure that the first such change

Return to bug 34967