Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1322362 > unrolled thread

Re: [PATCH] ld-version: fix it on Fedora

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ld-version: fix it on Fedora "Maciej W. Rozycki" <macro@imgtec.com> - 2016-01-30 14:40 +0100
    Re: [PATCH] ld-version: fix it on Fedora "Maciej W. Rozycki" <macro@imgtec.com> - 2016-01-31 16:10 +0100

#1322362 — Re: [PATCH] ld-version: fix it on Fedora

On Mon, 25 Jan 2016, Alexander Kapshuk wrote:

> > > At the moment, I'm wondering whether we really need to handle more 
> > > than three version number components. Another thought is that the 
> > > comparison could be inside ld-version.sh (or a replacement) so that 
> > > it can compare the array of version components directly instead of 
> > > using a constructed integer as a proxy.

 I don't think going beyond three version number components makes sense, 
to be honest.  Any such numbers will be non-standard third-party releases.  
Upstream binutils use a three-component versioning scheme.  Even the third 
component only makes sense because sometime we may actually rely on a bug 
fix first available with a maintenance release; these reach single-digit 
numbers only and hardly ever above 1 actually as another base release is 
usually made quickly enough (the usual schedule was annual, although as 
from 2.26, out last Monday, it has been switched to a semi-annual cycle).

> I put the latter of the two methods that worked for you it into a
> script, shown below:
> 
> #!/usr/bin/awk -f
> # extract linker version number from stdin and turn into single number
> 
> /[0-9]+([.]?[0-9]+)+/ && !/not found$/{
>     match($0, /[0-9]+([.]?[0-9]+)+/)
>     ver=substr($0,RSTART,RLENGTH)
>     split(ver, a, ".")
>     print a[1]*10000000 + a[2]*100000 + a[3]*1000
>     exit
> }
> 
> And tried it out on the following input:
> 
> % echo 2.24.51.20140217 | ld-version.sh
> 22451000

 So the above version is a non-release snapshot from the development tree 
as the repository trunk is switched to x.y+1.51 once a release branch for 
x.y has been made.  Then the release branch is switched to x.y-1.90 for 
prereleases, before settling on x.y or x.y.0 (this hasn't been consistent) 
for the actual base release.  Any subsequent maintenance releases will 
then have their version set to x.y.1, x.y.2, and so on.  We shouldn't ever 
rely on versions that are not proper releases.

> % echo 'GNU ld version 2.25-15.fc23' | ld-version.sh
> 22500000

 So this is a base 2.25 release (obviously with vendor patches, hopefully 
not breaking what we might rely on).

 FWIW,

  Maciej

[toc] | [next] | [standalone]

#1322666

On Sat, 30 Jan 2016, Maciej W. Rozycki wrote:

> > % echo 2.24.51.20140217 | ld-version.sh
> > 22451000
> 
>  So the above version is a non-release snapshot from the development tree 
> as the repository trunk is switched to x.y+1.51 once a release branch for 
> x.y has been made.  Then the release branch is switched to x.y-1.90 for 
> prereleases, before settling on x.y or x.y.0 (this hasn't been consistent) 
> for the actual base release.  Any subsequent maintenance releases will 
> then have their version set to x.y.1, x.y.2, and so on.  We shouldn't ever 
> rely on versions that are not proper releases.

 I need to correct myself here for unclear notation or off-by-one errors, 
the flow is of course as follows:

    trunk
   x.y-1.51
      |
      |
      |
release branchpoint
      |      \
    x.y.51 x.y-1.90
      |   prerelease
      |       |
      |       |
      v    x.y-1.91
      .   prerelease
      .       |
      .       |
              |
           x.y-1.92
          prerelease
              .
              .
              .
            x.y.0
         base release
              |
              |
              |
            x.y.1
      maintenance release
              |
              |
              |
            x.y.2
      maintenance release
              |
              v
              .
              .
              .

 The revision number is sometimes bumped up on trunk as well, to 52, 53, 
etc., though the criteria are not completely clear to me; perhaps to make 
a trunk snapshot "release".

 And last but not least for non-release builds the snapshot date is 
automatically appended to the version number reported, as seen above.

  Maciej

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web