Are you building NuGet packages for your tools, utilities and libraries?
Check.
Are you using SemVer for versioning? Check.
Then you might want an easy way of offering your (internal) packages, sorting them between Release and Prerelease for example. Release Views is what you are looking for.
What is really brilliant is that you already have a baseline set: Release and Prerelease. You don’t have to configure anything, it is already there for you.
What makes lots of sense IMHO is to divide them into Release, Prerelease and CI.
That’s because even if we would all love to have a single feed where you can get all the packages in an independent fashion, it is highly likely that some users might not need a CI package but something more refined instead.
With the latter it is clear that the package is not as good as a beta, making it easier to section your offer for the user as you like. CI is really bleeding edge sometimes, and I believe it is good to have it separated from other builds.
Are you using SemVer for versioning? Check.
Then you might want an easy way of offering your (internal) packages, sorting them between Release and Prerelease for example. Release Views is what you are looking for.
What is really brilliant is that you already have a baseline set: Release and Prerelease. You don’t have to configure anything, it is already there for you.
What makes lots of sense IMHO is to divide them into Release, Prerelease and CI.
That’s because even if we would all love to have a single feed where you can get all the packages in an independent fashion, it is highly likely that some users might not need a CI package but something more refined instead.
With the latter it is clear that the package is not as good as a beta, making it easier to section your offer for the user as you like. CI is really bleeding edge sometimes, and I believe it is good to have it separated from other builds.
No comments:
Post a Comment