Compare releases
Compare releases and check for compatibility between your existing Octopus Server and new releases.
What's new
These are the most important features you'll get by upgrading from 4.1.10 to 2018.1.4
Octopus 2018.1
Changes in 2018.1
See our release blog post for more details.
New Features
This January release of Octopus Deploy is primarily a security release driven by Octopus Cloud and will also benefit each of our customers running Octopus Deploy on-premises. We highly recommend upgrading.
You'll also notice our new versioning strategy: what would normally have been Octopus 4.2
is actually 2018.1
. Read more about why we changed.
Improvements
- When installing Octopus Server and using a Custom Windows Account to run the service, the installation wizard will configure SQL Server correctly so the Custom Windows Account can access the database
- Steps may now be explicitly configured to run before or after package acquisition
- The built-in worker, which executes deployment steps and scripts on the Octopus Server, can now be configured to run using a different, lower-privileged user account
- Fix for infrastructure overview not correctly flowing tag sets from associated tenants
- Import using the Octopus migrator finds the correct deployment process for scripts from similarly named projects
- Existing orphaned channels and releases are removed from the database
- The check to see whether a step template is in use is now much quicker
- Environments, channels and tags now cannot be deleted if they are used by a disabled step in a project's current process
- Package notes are fetched in bulk and in async, meaning a release can be deployed without all notes being downloaded first
- The installed version of Octopus Server is now tracked to help us provide support when data issues occur and is a precursor to raising and event on upgrade
Breaking Changes
Auto machine removal now happens as part of health checks. Minor breaking change API endpoint for machine removal logs is removed and machine removal logs are no longer stored on the Octopus server
Upgrading
All of the usual steps for upgrading Octopus Deploy apply.
Octopus 4.1
Changes in 4.1
See our release blog post for more details.
New Features
This December release of Octopus continues the support for Java that was introduced back in 3.17, with the ability to export certificates as Java KeyStores, as well as configuring certificates directly within existing Tomcat 7+, WildFly 10+ and Red Hat JBoss EAP 6+ application servers. This release also allows Maven repositories to be configured as external Octopus feeds, meaning Octopus can now consume Maven artifacts as part of a deployment.
Improvements
- Maven repositories as external feeds
- Deployment of Java keystores and configuration of certificates in WildFly, JBoss EAP and Tomcat
- Directories for task logs, artifacts and the package repository are now store as relative paths
Breaking Changes
There are no breaking changes in this release.
Upgrading
All of the usual steps for upgrading Octopus Deploy apply.
Release notes
These are the features and fixes you'll get by upgrading from 4.1.10 to 2018.1.4.
Changes in Octopus Server 2018.1.4
- 4123 - Package Acquisition no longer fails with a
Object reference not set
error when multiple deployments attempt to access the package cache - 4189 - Ensure the artifact list does not reset when the page auto-refreshes
- 4196 - Octopus.Machine.Hostname system variable is now available on transient target
- 4199 - Fix a bug where ‘Include Library Variable Sets’ in Project Library Sets page deselects existing Library Variable Sets when opened before Sets are rendered
- 4201 - Run-on-server script steps can now be run on a Tentacle that runs a under a different user account
- 4212 - The project dashboard release filter can now be specified by version number in the query string
- 4226 - Making deployment target discovery UI more intuitive
- 4232 - Replaced the Start Mode section in the IIS deployment step with bindable checkboxes in the Web Site and Application Pool sections
Changes in Octopus Server 2018.1.3
- 4137 - Allow configuration of
LicenseNotificationMode
viaconfigure
command - 4179 - Fixed issue where tag sets re-order feature is missing from the portal
- 4184 - When collecting an artifact using New-OctopusArtifact, we now allow other processes to access the file
- 4207 - Fixed issue where updating Calamari required higher permissions than necessary
- 4217 - Add Feed button not visible without AdministerSystem permission
- 4224 - Fixed a bug in JsonEscape variable substitution filter
- 4182 - Fixed issue where manual intervention instructions couldn't be bound to a variable
Changes in Octopus Server 2018.1.2
Changes in Octopus Server 2018.1.1
Changes in Octopus Server 2018.1.0
- 3317 - When installing Octopus Server and using a Custom Windows Account to run the service, the installation wizard will configure SQL Server correctly so the Custom Windows Account can access the database
- 3924 - Auto machine removal now happens as part of health checks. Minor breaking change API endpoint for machine removal logs is removed and machine removal logs are no longer stored on the Octopus server
- 3974 - Steps may now be explicitly configured to run before or after package acquisition
- 4070 - The built-in worker, which executes deployment steps and scripts on the Octopus Server, can now be configured to run using a different, lower-privileged user account
- 4143 - Fix for infrastructure overview not correctly flowing tag sets from associated tenants
- 4144 - Import using the Octopus migrator finds the correct deployment process for scripts from similarly named projects
- 4157 - Existing orphaned channels and releases are removed from the database
- 4183 - The check to see whether a step template is in use is now much quicker
- 4185 - Environments, channels and tags now cannot be deleted if they are used by a disabled step in a project's current process
- 4192 - Package notes are fetched in bulk and in async, meaning a release can be deployed without all notes being downloaded first
- 4194 - The installed version of Octopus Server is now tracked to help us provide support when data issues occur and is a precursor to raising and event on upgrade
Changes in Octopus Server 4.1.10
- 2668 - The database upgrade now checks whether the licence would be non-compliant after upgrade and aborts the upgrade in order to prevent getting stuck with an expired licence and not being able to deploy
- 3454 - Digitally signed
Octo.exe
andOctopus.Clients.dll
so that AV respects it more - 3802 - Added support for passing password on the commandline to docker login
- 3910 - Added option to filter by phase name in lifecycles page
- 4040 - Minor breaking changes Project and tenant name cannot include unsupported file system characters
- 4102 - Now we only test the connection to the
master
database when creating or deleting the Octopus database, which in turn fixes a problem we introduced in4.1.0
with upgrading Octopus in certain situations - 4130 - PowerShell script parameters with a trailing slash no longer break script execution
- 4155 - Fix a bug where metadata component in release version is not working with SemVer 2.0 template
- 4162 - Added the ability to prevent package scripts from being run by specifying the
Octopus.Action.Package.RunScripts
variable and setting it tofalse
- 4165 - We no longer attempt to deploy packages when acquisition fails
- 4169 - Fix for deployment process screen where viewing email step that references a deleted team
- 4171 - Don`t show username for external groups in teams area
- 4174 - Dynamic package feeds now working again with channel rules
- 4187 - Check for $JAVAHOME now uses [[ -n "${JAVAHOME}" ]] instead of -v to support older versions of bash