microsoft
Repositories use the earliest version of the the dependency instead of the latest version
i have a lot of repositories that uses another repository as a dependency , so i used appDependencyProbingPaths with the latest version of the release , however instead of getting the latest version of the release , the workflow gets the earliest version of the release , is there any fix for this problem ?
This might be a bug
The version it finds, is that the latest version, which was released from the main branch? It looks like the assets in the version you are expecting was released from the Release branch, right?
both versions got released from the release branch , what i was expecting is the workflow will get the latest version of the release with tag 'latest' but somehow it ignores the tag and ignores all the recent versions and the workflow uses the earliest version of the extension
Yes, freddyk at Microsoft dot com
Sendt fra Outlook til iOShttps://aka.ms/o0ukef
Fra: ismailhafid1 @.> Sendt: Wednesday, May 8, 2024 12:52:59 PM Til: microsoft/AL-Go @.> Cc: Freddy Kristiansen @.>; Comment @.> Emne: Re: [microsoft/AL-Go] Repositories use the earliest version of the the dependency instead of the latest version (Issue #1069)
can i send the full build log via email ?
— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/AL-Go/issues/1069#issuecomment-2100405483, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACSGUA3TTSARWYVPZC7VXXLZBIGZXAVCNFSM6AAAAABHIWCUZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBQGQYDKNBYGM. You are receiving this because you commented.Message ID: @.***>
Hello @freddydk , it s been two weeks and we can't find a way to solve this problem , and our workflows don't work because this problem , is there any news or any fix resolve this issue ?
This documentation in the workshop explains in details how releases are sorted: https://github.com/microsoft/AL-Go/blob/main/Workshop/Releasing.md
If you go to releases in your repository - the latest release is indeed your v1.0 and not the other releases and the reason for this is that GitHub uses the tag_name (not the name, which can be anything) to sort the releases.
The tag_name needs to be semver and the sorted tag_names are
which puts 23.0.0 (v1) on top.
I think it is possible to edit the tag name for a release - but haven't tried.