[Dnsmasq-discuss] Announce: dnsmasq-2.84 - sort and semantic versioning

[Geert Stappers]

On Sun, Jan 31, 2021 at 12:21:11PM +0100, Geert Stappers wrote:
> De : Simon Kelley <simon at thekelleys.org.uk>
> Envoyé : samedi 30 janvier 2021 00:19
> > On 26/01/2021 16:55, M. Buecher wrote:
> > > On 2021-01-26 17:41, M. Buecher wrote:
> > >> On 2021-01-26 00:43, Lonnie Abelbeck wrote:
> > >>> On Jan 25, 2021, at 5:21 PM, Lonnie Abelbeck wrote:
> > >>>>
> > >>>> The version string generated is "2.84rc2"
> > >>>>
> > >>>> $ cat dnsmasq-2.84/VERSION
> > >>>> (HEAD -> master, tag: v2.84rc2, tag: v2.84, origin/master, origin/HEAD)
> > >>>
> > >>> This patch solves the problem:
>            ...
> > >>>
> > >>
> > >> Actually sort is not good at sorting semantic versions [1].
> > >> In some cases '-r' will work (2.84, 2.83-post1, 2.83) and in others it
> > >> won't (2.84-rc1, 2.84, 2.83). Same applies for sort without '-r'.
> > >>
> > >> [1] https://semver.org/
> > >>
> > >> Just my two cents
> > >> Maddes
> > >
> > > Forgot to reference the details for sort's -V|--version-sort option at
> > > https://www.gnu.org/software/coreutils/manual/coreutils.html#Implementation-Details
> 
> Thanks for providing that good information.
> 
> 
> > > Other wrote scripts in other languages like php, Python, etc., e.g.
> > > https://gist.github.com/andkirby/54204328823febad9d34422427b1937b
> > >
> > >
> > 
> > Lonnie's patch exactly reverses f4f400776b3c1aa303d1a0fcd500f0ab5bc970f2
> > from 2015, which I guess was to address a problem with a different set
> > of version strings.
> > 
> > After a certain amount of trial and error, I've managed to coax sort
> > into doing the right thing for version strings which dnsmasq uses.
> > 
> > v2.84 sorts before v2.83, but v2.83 sorts before v2.83rc1 and 2.83rc1
> > sorts before v2.83test1
> > 
> > 
> > It's not pretty:
> > 
> >  sort -k1.2,1.5r -k 1.6,1.6 -k1.8,1.9r -k1.10,1.11r
>  
> 
> Besides not pretty,  it is also not readable.
> Plus '-k 1.6,1.6' looks very odd in that line. 
> 
> |  sort -k1.2,1.5r -k1.6,1.7r -k1.8,1.9r -k1.10,1.11r
> looks more "having a pattern"
> 
> 
> Frankly I think we are repairing at the wrong place.
> Instead of handcrafting a sort algoritme, we should repair our
> versioning name convention.  Tilde to the  rescue   :-)
> 
> $ cat << HERE > old_convention
> v2.83
> v2.84test1
> v2.84test2
> v2.84rc1
> v2.84rc2
> v2.84
> HERE
> $ cat << HERE > new_convention
> v2.83
> v2.84~~test1
> v2.84~~test2
> v2.84~rc1
> v2.84~rc2
> v2.84
> HERE
> $ sort --version-sort old_convention 
> v2.83
> v2.84
> v2.84rc1
> v2.84rc2
> v2.84test1
> v2.84test2
> $ sort --version-sort new_convention 
> v2.83
> v2.84~~test1
> v2.84~~test2
> v2.84~rc1
> v2.84~rc2
> v2.84
> $ 
> 
> --- a/bld/get-version
> +++ b/bld/get-version
> @@ -9,9 +9,14 @@
>  # If we can find one which matches $v[0-9].* then we assume it's
>  # a version-number tag, else we just use the whole string.
>  # If there is more than one v[0-9].* tag, sort them and use the
> -# first. The insane arguments to the sort command are to ensure
> -# that, eg v2.64 comes before v2.63, but v2.63 comes before v2.63rc1
> -# and v2.63rc1 comes before v2.63test1
> +# last. This needs tilde character in the version, e.g.
> +#
> +#   v2.83
> +#   v2.84~~test1
> +#   v2.84~~test2
> +#   v2.84~rc1
> +#   v2.84~rc2
> +#   v2.84
>  
>  
>  # Change directory to the toplevel source directory.
> @@ -31,7 +36,7 @@ else
>       vers=`cat $1/VERSION | sed 's/[(), ]/,/ g' | tr ',' '\n' | grep ^v[0-9]`
>  
>       if [ $? -eq 0 ]; then
> -         echo "${vers}" | sort -k1.2,1.5r -k 1.6,1.6 -k1.8,1.9r -k1.10,1.11r | head -n 1 | sed 's/^v//'
> +         echo "${vers}" | sort --version-sort | tail -n 1 | sed 's/^v//'
>       else
>           cat $1/VERSION
>       fi
> 
> 
> 
> > I'm assuming that people don't want yet another release just to fix
> > this, but if I've assumed wrong, let me know.
> 
> Lonnie Abelbeck's hint on another release was indeed very humble
> and very polite. And yes, he is right with expressing
>   We do ourself and the rest of mankind a favour by avoiding
>   version string "2.84rc2" for verion "2.84"
> 

Meanwhile I learnt they are the same. Both git tags are
on the same git commit.

commit 20295012b8815d0989332516c6ac51018746e92e (tag: v2.84rc2, tag: v2.84)



Groeten
Geert Stappers
-- 
Silence is hard to parse