Thanks for the answer, I'll ask the team!

Hello @bkohler_1524, Because packages are immutable, you need to decide the future-compatibility at the time you create the package. This is where Semantic Versioning dependencies can really help. Following the rules of SemVer, you can say that "ProductA 1.0.0 has a dependency on ProductB (1.1.0-2.0.0]", what that means is that you can use every version of ProductB from 1.1.10 up to (but not including) 2.0.0. This allows you to make as many minor versions of ProductB (such as 1.200.0) before "breaking" compatibility. If these version numbers are business/marketing-driven, and it's impossible to change their mind on versioning, you can always maintain an internal version number - this is what many products (such as Microsoft) does.

Hi @nuno-ildefonso_8876 , Thanks for that information; this will be fixed in the next maintenance release (BM-3788), later this week (on Friday).

Thank you, @rhessinger, for clarification. Yes, I use common blob storage, and all that makes sense now.

Good news

Hi @testing-avram1_6229, Can you please tell me what version of BuildMaster you are using and what version of the BuildMaster agent you have installed? Also, if you change the BuildMaster agent to a Delayed Start instead of an Automatic start on your remote server, do you see the same issue? Thanks, Rich

Hi @NUt , Thank you for bringing this to our attention. This bug, PG-2126, will be fixed in ProGet 6.0.12. Going forward it will allow you to configure everything and even test it via the "Test User Directories" button, but it will only allow you to login using the Built-In user directory and the username/password login option when using ProGet free. Thanks, Rich

Hi @afd-compras_2365 , This is the second request for the feature - but I'll bring this up at our engineering meeting. @benjamin-soddy_9591 is there something more you can add to the conversation ? Cheers Nanci

hi @ab-korneev_0401 , By "debugging", we mean running the ProGet code inside of Visual Studio's "debug mode". That will show the errors let us see quickly how to fix them. I'm afraid it's not easy to identify the problem without it, since it's very likely a bug in the third-party repository you're using. Since it's not possible to provide that information, can you... create a server on AWS LightSail (or similar cloud service) Install the same type of third-party repository software and configure it in same manner upload one or two packages that reproduce the problem verify the problem in ProGet Then, send us the information of the server, and we can look at it through the debug mode

Hi @dm-sidelnikov_5266, Glad to hear it! Please let us know if you have any other questions. Thanks, Rich

@mcascone I don't think it's new, but it's just used to specify the dependencies field in the manifest file; I'm thinking, perhaps, it might be similar/identical to the consumes field you added? https://docs.inedo.com/docs/upack-universal-packages-manifest The only thing Inedo tools use it for today is just displaying information in ProGet, on the dependencies tab. That may / may not be helpful.

Hi @stevedennis, having a PackageLicense table would be great for two reasons: a) It would give as the ability to do some reporting on used licenses. b) There are lots of packages that use embedded license files. ProGet already has a feature where we can manually assign the corresponding license to a specific version of a package, but as far as I can tell, this is done by generating a pseudo URL for each package and assigning that URL to the corresponding license. While this does work fine as long as it is done only for a small number of packages, I'm not so sure how it affect usability (and maybe performance) when this is done on a larger scale. Having a separate table that connects packages (or package versions) to specific licenses might be a cleaner way to store and process that information. I'd have to check whether we could give you a dump of our database, but we are only just starting to use ProGet, so there isn't really too much data there yet. The fact that we are new to this is actually the reason we are so interested in reports about licenses and vulnerabilities: We are setting up workflows, etc. and at some point we want to completely block downloads of vulnerable packages or packages that use restrictive/unknown licenses, but before we activate hard filtering rules we want to get an overview on how this would affect products currently in development (so we can adapt our rules or define exceptions). At the moment we are generating data by integrating pgscan to our build pipelines and gathering download statistics for packages (and hope that we will be able to analyze that data in a useful way), so feel free to reach out in a month or so. Maybe we will have enough meaningful data to be of use for you guys by then. Cheers, Sebastian

Hi @atripp , after yours testing I found mistake in URL - my URL was without /package/. When I use proper URL to request, package was succesfully deleted. Thank you for quick support and sorry about my novice mistake ;)

Hi @mcascone, Thanks for following up and letting us know this worked! Thanks, Rich

Hi @kichikawa_2913, Could you please open another topic for the Selenium.WebDriver.ChromeDriver issue? I think that is unrelated to the authentication issue. Thanks, Rich

Hi @Russell-Kahler_4399 , It looks like there was an error running the upgrade scripts to v4.7. That would have been a long time ago, and it's hard to guess what it could be, and it'd require a bit of analysis to figure out. I'd recommend migrating to a new instance; you can use Feed Importers in the latest version to pull all the content from your existing instance. It's possible to bypass the errors with inedosql resolve-error --all but I really wouldn't recommend it, since it could lead to more problems. Cheers, Alana

@mcascone said in Proget: retention policy for branches in a package: This means mybranch and mybranch2 can be reduced to mybranch2. Sorry but wouldn't this be the reverse: *mybranch* will match *mybranch2*? What I mean to say.... because it's an AND conditional, the *mybranch* is effectively ignored. Everything that matches *mybranch2* will also match *mybranch*, but the opposite isn't true. E.g. mybranch1 won't match both conditions. @mcascone said in Proget: retention policy for branches in a package: in this feed, delete matches of 'mybranch', except the latest 3 versions of those matches, which would only impact the versions matching mybranch and leave all other non-matches untouched; Correct. And do note that you can set retention policies to run in dry mode, where nothing is deleted, to verify it's the behavior you want.

It seems to work normally now with the homepage setting to none. The default category is support. So I'm happy! Thanks!