SQL change automation & .NET Framework

Dominick

Recently I started seeing the below message while doing an automated build using TFS.  The message is in the logs from the build agent.

The Requirements for SQL Change Automation will soon be updated to need .NET Framework 4.7.2, please ensure you upgrade your machine. See https://www.red-gate.com/sca/install-net472 for instructions  (The link just throws you over to a MS website to download .NET Framework)

Is there a date that we need to have the Build Agents upgraded?  Does the .NET upgrade correspond to a specific version of Change Automation?  We are running TFS on-prem, upgrading our build agents is not a "quick" task so I want to make sure we plan accordingly.  

Thanks

Russell D

We're hoping to have this work finished, then allowing for testing and releasing it will hopefully be out soon.

Russell D

We're hoping to have this work finished today, then allowing for testing and releasing it will hopefully be out soon.

Russell D

@Dominick we've decided to put this off until Early May due to feedback from people essentially requesting more time to upgrade, sorry for the change in plans.

PeterG

Hi Dominick,

We've just released the update, and to not take the upgrade if using a plugin you will need to pin the version of Sql Change Automation you pull down under the Sql Change Automation version configuration section to 3.1.18

Russell D

No ETA yet, I'll try and get a more helpful answer for you.

Dominick

Thanks for following up.  I am assuming it will not be a forced upgrade, so we could upgrade our .NET version by mid summer and upgrade at that time.  Thanks again....

samssb82

I'll take the blame for the issues my company has encountered related to this as I have been seeing the message in the logs.  I would like to request two things for future breaking changes though.  

1.  Please include a date in the message as to when the breaking change will be implemented.
2.  Please don't release it on a Friday.

Thanks!
Sam

Russell D

Thanks @samssb82 - I think with point 1 this would prove difficult, because to change logging messages requires a release, and as such with the natural volatility around release dates if that changed, we'd almost unwillingly have to commit to a release date that may not work for us (eg if testing fails) - it could cause a lot more harm than good.

2 - point taken and I will pass that on .

samssb82

Hi @Russell D,

Thanks for the response.  In relation to #1, it wouldn't have to be a hard date.  You could put an estimated date.  Saying "soon" isn't very descriptive.  If you had an estimated date, pending testing, of 5/10/2019, that would at least let us know we should be ready at that point in time.

Either way, we will attempt to put the required in changes in place soon after seeing future notifications.

Thanks,
Sam

Dominick

@Russel D,

Definitely understand about not being able to say an exact date, but once a date is known, it may be a good idea to send out an email to registered users if the minimum requirements are changing.  Even if this email came a week before, it would give teams a heads up that changes were coming and allow them to react BEFORE the push occurs. 

Thanks,

Dominick

Russell D

Understood and I'll pass that feedback on. Bear in mind though we're a tad reluctant to send out emails as they're a) easily ignored and b) reduce the impact of that communication channel for when we do really need it.