There are times when I have one machine that failed a step and I want to retry that step for that machine only, then continue to deploy the rest of the steps for all machines.

Hi
In the previous version of Octopus (2.6) the 2 following properties were availabe:
LastModifiedOn
LastModifiedBy
it sounds like there has been a decision to suppress them as part of version 3.x.
As admin I find this auditing information very useful, and if anything I think that auditing should improve (it is very hard to track changes at the moment) - so I suggest to bring it back.
See more info:
http://help.octopusdeploy.com/discussions/questions/7091-api-change-from-26-to-3213-missing-information
Thanks
Nir

Prior to v3 of octopus, when a step required guidance the yellow box would indicate which step required guidance. Since v3 the guidance box no longer indicates which step it relates to and since multiple guidance boxes can appear you can end up clicking on the wrong one to continue when you've sorted out whatever maybe the issue.

Please put an indicator of which step it is that requires guidance back in that yellow box.

For the support pages such as http://help.octopusdeploy.com/discussions/, consider a stackoverflow styled UI, such as the one used by Jira, https://answers.atlassian.com/questions

At the moment, I have to dump the $octopusParameters to the output on the PreDeploy script.

It would be handy to have a new tab that lists all those parameters.

-- TeamCity has a similar concept where it lists parameters used for a build

When deploying a release, there is a selection box listing each available environmentn for deployment. If would be great if each environment would indicate its current release, if any. We have a multi-tenant application with some clients on a previous version, and we always have to take note beforehand which environments are applicable for a new deployment.

In V2 a deployment with warnings hade a yellow warning sign on the dashboard.

In V3 that yellow sign is now white and looks more like a small "smudge" that one hardly notices...

With Role based security, if the have a variable that is use by two environments within the scope the user of least privileges cannot see their variables. I propose that it is made visible and not display the other environment within the scope.

Add support for Octopack Nuget so that MonoAndroid and Portable Libraries can be packed with Octopack.

Currently unable to install Octopack to portable library:
Could not install package 'OctoPack 3.0.44'. You are trying to install this package into a project that targets 'portable-net45 ....... (and so forth) ..

If an OD setup uses a large number of Environment Variables, it can be difficult, and slow to use them for reference.

i.e. #{EnvironmentPath}-#{Suffix}-#{SecondSuffix} isn't particularly helpful, especially if

EnvironmentPath = #{ServerLocation}-#{ServerType}-#{TenantInstance}

And if it nests further, it becomes incredibly slow to see how it will resolve on a deployment, short of deploying.

If there was a way, during snapshots, or ideally through a "show resolved for : " button, then this would make it easier to reference urls from OD2.

iam currently doing a full deploy to a staging envoirement were i do i backup/restore of a database and then set the certain values that is depending on the deployment, thats why when you create a deploy i want to be able to have some steps "skipped" by default.

TeamCity has the concept of Metarunners. These allow you to package up a sequence of build steps into a single new step and reuse the sequence across multiple builds. We have a standard set of approvals that are required for deployment to certain environments. It would be nice to be able to define these approval steps once and share it to all of our applications instead of having to manage the entire process in each application directly.

Our company deploys all projects to all environments to simplify the process at deployment time. The problem is we can't distinguish from the dashboard what environments actually have the code deployed and which ones do not because not all code goes to every environment based on the roles. If we could toggle between what has been attempted in each environment and what has actually been deployed, it would simplify post deployment queries. The toggle could be based off the same switch that determines when the retention policy is applied during deployment.

I want to be able to drop a nuget package and run post deploy scripts without deploying it to an application.
In my case I want this to be just a package that contains migrations, usually for data fixes, which I can deploy without redeploy an app or have have fake apps in my servers.
At the moment if I do that (just deploy a package), and not select a windows service/web app deploy the PostDeploy.ps1 in the nuget package never gets executed.

I'm running Octopus Deploy 3.1.1 and some of our Tentacles are running versions 3.0 and 3.1.

One the Environment page, the environments that contain old Tentacles say "Upgrade suggested" which is fine as I understand any 3.0 Tentacle is compatible.

However at the top of the Environment page the banner says "Tentacle upgrade required".

So is the upgrade required (seeming mandatory to continue operation), or just suggested? I feel a tweak to the wording would create a more consistent reflection of what needs doing.

We have a multi-tenant setup, with one environment per client. Since we often have multiple minor releases in production at a time, it would be great to see at a glance which version is currently deployed to each environment on the "Deploy release" screen (/deployments/create) so that it's easier to pick the right clients to update.