This is a follow up to https://forums.inedo.com/post/13488 but I am wondering about the mentioned "API that would work across all package types" for package deletion. Is this feature still being planned for ProGet 2023?

What I'm after is a retention policy of "last X builds of each version" which doesn't seem possible with the current combinations and so one idea I had was to script the deletion from the outside using this REST API like I do now for NuGet (need to do it for maven too).

The other idea I had was making retentions rules have a scripting option (something like passing in the artifact ID and list of versions, and returning either a list of versions to keep or versions to delete, whichever is easier to implement) but that would be a new feature request that may not provide a lot of benefit for users other than us.

Thanks! Looking forward to that.

I am looking into repackaging and promoting from an internal Proget server to public nuget.org but in the process I cannot see a way to download the snupkg file. I see an option in the web UI called "download with symbols" but I'm wondering if that only applies to the legacy symbol format. I also tried using GET on the symbolpackage API that I noticed when uploading via nuget CLI, but that told me that the package ID was not specified or something. So is there a way to download the snupkg so that I can then reupload it to nuget.org ?

@atripp Thanks!

The docs indicate to start using the tag "latest" which is supposed to mean "give me the latest version" however as of the time of writing this post, it appears that latest points to 22.0.9 when 22.0.10 - 22.0.13 are available. Even the "22" and "22.0" tags continues to point to an older version. Is this by design, and if so what design?

According to this post, the class org.apache.maven.artifact.versioning.ComparableVersion is the source of truth for how maven verisons are sorted, but ProGet maven feeds don't seem to follow this. For example, given the versions 3.1.0-9 and 3.1.0-10, the class will sort them numerically so they are in the order provided just now. ProGet, on the other hand, sorts them lexographically and considers 3.1.0-9 higher than 3.1.0-10. There are probably other weird quirks as well but this is the one that I am concerned with. The retention rules for "keep X latest versions" will delete the wrong artifacts because of this.

This is what I used to prove the above:

import java.util.Arrays;
import org.apache.maven.artifact.versioning.ComparableVersion;

public class App 
{
    private static final ComparableVersion[] VERSIONS = new ComparableVersion[]{
        new ComparableVersion("3.1.0-10"),
        new ComparableVersion("3.1.0-9")
    };

    public static void main( String[] args )
    {
        Arrays.sort(VERSIONS);
        for (ComparableVersion v : VERSIONS) {
            System.out.println(v);
        }
    }
}

The resulting output is

3.1.0-9
3.1.0-10

Gosh sorry, I actually forgot to copy the new backup before trying again so the result is that the second variant of these backup and restore do not work (I took these from an older version of the documentation) but the first variants do (these are in the current docs)

I have been using proget for quite a while and it's overdue for an upgrade due to various bugs that have been fixed in newer versions, and while I'm at it I would like to upgrade to MSSQL database instance from 2017 to 2022. My thought process is that this would be:

1. Start new MSSQL docker instance
2. Backup current MSSQL docker instance
3. Start new proget docker instance pointed at the new database

However, I find when I do this the docker feed has vanished according to the newly spun up proget instance. Is there a step I am missing. This is the command I used to backup from MSSQL 2017:

(I tried both of the following):

docker exec -it proget-sql /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q "BACKUP DATABASE [ProGet] TO DISK = N'/var/opt/mssql/backup/backup.bak' WITH FORMAT"
docker exec -it proget-sql /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q "BACKUP DATABASE [ProGet] TO DISK = N'/var/opt/mssql/backup/backup.bak' WITH NOFORMAT, NOINIT, NAME = 'ProGet-full', SKIP, NOREWIND, NOUNLOAD, STATS = 10"

Then after copying out of docker and into the new docker instance, I restore the new instance:

(I tried both of the following)
docker exec -it proget-sql-2022 /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q 'RESTORE DATABASE ProGet FROM DISK = "/var/opt/mssql/backup/backup.bak" WITH FILE = 1, NOUNLOAD, STATS = 10'
docker exec -it proget-sql-2022 /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P $(cat mssql-pass.txt) -Q 'RESTORE DATABASE ProGet FROM DISK = "/var/opt/mssql/backup/backup.bak" WITH MOVE "ProGet" TO "/var/opt/mssql/data/ProGet.mdf", MOVE "ProGet_log" TO "/var/opt/mssql/data/ProGet_log.ldf"'

Either way, the docker feed is missing when the new instance is spun up. Is there any way to resolve this?

Oh, if you meant an example with embedded icon, .NET official packages do this too:

https://www.nuget.org/packages/System.Collections.Immutable/7.0.0-rc.1.22426.10

Sorry I didn't notice this reply! Sure, our published packages have used embedded licenses for several versions now. Here is one -> https://www.nuget.org/api/v2/package/Couchbase.Lite/3.0.2 and here is a link to how the server shows it https://www.nuget.org/packages/Couchbase.Lite/3.0.2/License