I’m voting again for this feature request: http://servicestack.uservoice.com/forums/176786-feature-requests/suggestions/4780249-add-a-ci-step-that-tags-the-release-number-into-th
Without tagging the repos with each publicly available NuGet release, it makes my life as a ServiceStack developer very difficult to figure out what exactly is in each release.
Here’s the release pattern I’ve observed for v4.x development:
- Target is to deploy to NuGet once every 2 weeks
- Reality is that on the day of deployment there are often a dozen commits that day. Some of of them will have been deployed, some not.
- Often the first attempt at deploying the “next” release to NuGet is replaced within 24 hours after a critical flaw is found. (4.0.13 replaced 4.0.12 within hours. 4.0.17 replaced 4.0.16 within hours).
- There is no way of knowing which commit from each SS repo actually got deployed to NuGet
The release deployment mechanism for ServiceStack needs to be improved so that all of us developers know what will be in each release. The current workflow does not provide developers with enough visibility to know what is actually in any release.
ok I can look at creating a new release on GitHub after I deploy to NuGet, but this would have to be a manual process after each NuGet deployment.
I’ve just done this for v4.0.17 on the major repos, i.e: SS, SS.Text, SS.Redis, SS.OrmLite
Doug Schmidt:
BTW, thanks for this change, Demis. It’s already making my life easier to figure out what’s changed between releases.