[ProGet] Recently Published Rule

[tim.vanryzin_8423]

Hi.

We'd like to implement the recently published rule. Before we do we are not sure of how the developer experience will be. Will it be obvious that they are not getting the latest package even though I just ran an update to get latest? For example when they go to the online repo it says the latest is 1.12.15 but when upgraded they get 1.12.10.

Any thoughts on this are appreciated.

[stevedennis]

Hi @tim-vanryzin_8423 ,

Great question on developer experience! We're very curious to learn that ourselves, so please let us know as you implement it.

First and foremost, if you haven't already, check out the Recently Published & Aged Packages rules blog article to see how this works and our current advice. FYI - we are likely going to change the best practices guidance in 2026 to discourage download blocking.

From an API/technical standpoint, it's simply not possible to "hide" the fact that 1.12.15 is the latest version. So, if you have a connector, ProGet will report the latest version as reported by the connector.

But even it were technically possible, there's no simply great developer experience here. Keep in mind that most never look at the ProGet ui -- they configure things once, and forgeet about it.

So really, it's just a question of when you want the developer to find out they can't use Xyz-1.12.15. Here are the general options:

• Manual Curation (no connectors) - it's always going to be on nuget.org / npmjs.org, so even if you manually curate every page in ProGet, they'll know it exists and will be confused why it's not on ProGet; they may not even know who to ask
• Download blocking - you could simply block downloads of newest packages, but that's just going to look like random "400 errors" to developers and they will become frustrated
• Build Auditing - run pgutil builds audit on your build server, and you can see if the packages are noncompliant; this is where we are shifting our advice, as a failed build at that stage will be so much more obvious than a 400 buried in a package restore step

Ultimately this requires training developers to use lock files and not always get latest. That's why we are shifting to pgutil builds audit -- it's almost self-training. When their builds fail, they will see the reason clearly and should be able to adjust their code/configuration to not use a non-compliant version.

-- Dean

[tim.vanryzin_8423]

Thank you. Super helpfull!