Just to give you a heads up. I'm already on version 2023.32 and it works like a charm. Thank you.

Hi @andrewwickham_1641, Thanks for giving us an update and letting us know that fixed your issue. Thanks, Rich

Hello; Does your server have Internet access? That is an ancient version of the Inedo Hub... I would uninstall the Inedo Hub, and then download it again. Hopefully the error will be resolved then. Cheers, Nanci

Thanks very much, Scott. You helped me by mentioning that the feeds themselves also need to support SemVer 2.0. I wasn't aware of that fact. So I just migrated our feeds an now everything works fine.

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370 Took a bit, but CRAN (R) feeds have arrived https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

Great to hear it got fixed. Thanks !

If you want developers to always be able to use any version of a package, then you should configure a connector to that remote resource. Then, they will always be able to download the latest version of the packages they need, and ProGet will cache those packages.

Please disable the "Overwrite Package" permission in Admin > Tasks. Then, you will get "Package Already Exists" error

I'm not sure if I totally understand the question, but packages are designed to be immutable, and as such you really can't "update" them. You can delete or overwrite a package if you have permissions, but it's inadvisable and you should not make this part of your workflow. In addition to being against the fundamental package workflow/design guidelines, packages are cached by clients like Visual Studio, and won't see a "new version" of a "version" of a package.

Thanks. FYI: Retention policies should be ignored on free versions. But UNKNOWN does indicate the service user; so it's likely a retention policy job (which is run as part of feed cleanup). You can see the logs of those, and maybe see some more info...

I'm afraid I don't really understand the requirements for what you're trying to accomplish... Here are the differences between the two extensibility points: A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic. A Package Access Rule Allows for rules to block downloads of packages based on additional logic. The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

It is a working feature, but there are some known issues (PG-1343 and PG-1344) that we will have fixed soon. You can find the documentation here.

Hi Clint, Sorry for the slow response. There is no current way to do this at the role level, but we could possibly add this as a feature. If you'd like it, check out our new feature request process, and we can see about assessing it. Thanks!

This is by design; it is the responsibility of a package author to license a package, and make sure that it's a standard license. This way, automated licensing monitoring can catch it. However, as you've noticed, this isn't the case for a lot of open source packages. So, in this case, you'll want to use a different workflow. Just create a "approved packages" feed, and promote approved packages into these feeds.

Hi Josh, Sorry, this seems to be a v6 glitch! But we're on it :) I've submitted BM-3192 and then inedo-docs/#6 to update our documentation. Your understanding of how the feature is supposed to work is correct, and your use-case is how it's supposed to be. Thanks for reporting it !

I'm not too familiar with how OneGet fits into all this; you'd really be better asking this question at the Chocolatey or OneGet forum. You'll still use ProGet to host the packages, but I'm really not sure which client tool (choco, etc) will do the download and install on a desktop.

Thank you with version 4.8.12, it's working.

See my response here. In summary, it's not a valid SemVer2 version number because it contains 4 parts before the hyphen, and it's not a valid legacy version number because it contains a . after the hyphen.

I think your best bet is really going to be to use Universal Packages for this. That's what they're designed for, and the operations are much easier to use for it. We very recently updated our documentation to give some guidance on this: https://inedo.com/support/documentation/proget/core-concepts/packages NuGet is designed for .NET library files to be used in developing .NET-based software. Maven is similar, but Java; you should use Maven for packaging up Java code that Java developers will use to build other JAva applications. The applications themselves should be packaged in a universal format.

It looks like this is just an oversight on our part, because the unlisted package is the latest version. I've logged this as PG-1194 and scheduled to fix in a maintenance release.