Hi Vagrant,
> Rather than picking an arbitrary incremental number, I have in the past
> used something based on the results from git describe... e.g. in my
> current checkout of guix:
>
> $ git describe --match=v1.4'*'
> v1.4.0-142685-gfc059c66cf
>
> e.g. 142685 commits past v1.4.0, with the c
On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh
wrote:
>
>
> Vagrant Cascadian vagr...@debian.org writes:
>
> > Rather than picking an arbitrary incremental number, I have in the past
> > used something based on the results from git describe... e.g. in my
> > current checkout
Vagrant Cascadian writes:
> Rather than picking an arbitrary incremental number, I have in the past
> used something based on the results from git describe... e.g. in my
> current checkout of guix:
>
> $ git describe --match=v1.4'*'
> v1.4.0-142685-gfc059c66cf
>
> e.g. 142685 commits past v1.
While others have pointed out the workflow fix,
On 2024-09-23 10:22, Konrad Hinsen wrote:
If both packages have the same version, then the
command line tools will warn about the ambiguous package
specification. If the version numbers are different, then the tools
will quietly choose the "newer"
On 2024-09-23, Andreas Enge wrote:
> Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen:
>> $ guix show -L . sbcl-websocket-driver
>> name: sbcl-websocket-driver
>> version: 0.2.0-0.df94496
>> location: gnu/packages/lisp-xyz.scm:30847:4
>> It looks like Guix picked the larger on
Hi Andreas,
>> It looks like Guix picked the larger one by
>> alphanumeric order, which is not a reasonable choice in a development
>> context.
>
> This is exactly the role of the number "-0." in front of the git commit;
> one needs to specify by hand the order of the (non-)releases, as coming
Go
Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen:
> $ guix show -L . sbcl-websocket-driver
> name: sbcl-websocket-driver
> version: 0.2.0-0.df94496
> location: gnu/packages/lisp-xyz.scm:30847:4
> It looks like Guix picked the larger one by
> alphanumeric order, which is not a
Hi Kaelyn,
> Whether it does or doesn't depends on the versions of the duplicate
> packages in question. If both packages have the same version, then the
> command line tools will warn about the ambiguous package
> specification. If the version numbers are different, then the tools
> will quietly
