Align the worker package to Sql package

[MaddyDev]

We have given a range for the SQL webjobs package dependency of the Worker and that could cause issues when we have multiple package releases targeting different versions.
Ex scenario: 3.0.343-preview worker package has dependency on 3.0.343-preview Web Jobs package
Since we gave a range for that dependency, when customer runs the 3.0.343-preview worker package, it can pull the 3.0.399-preview SQL web jobs package which has all the package upgrades and could cause issues.

In order to avoid this, am removing the range and coupling it with the webjobs package version. What this entails is that every time we release the webjobs, we release the corresponding worker package as well. I'll make changes to the Release pipeline to release both the packages every time.

[Charles-Gagnon]

which has all the package upgrades and cause issues.

What kind of updates and issues are you referring to?

I would normally expect that a build version change (3.0.343 -> 3.0.399 for example) wouldn't have any breaking changes. Is this not the case?

[MaddyDev]

which has all the package upgrades and cause issues.

What kind of updates and issues are you referring to?

I would normally expect that a build version change (3.0.343 -> 3.0.343 for example) wouldn't have any breaking changes. Is this not the case?

In our case, we upgraded all package dependencies to latest , MDS update caused the .NET 7 issue. So even if the user is using an older worker package 3.0.343, it pulls the latest Web Jobs package 3.0.399 instead of the corresponding 3.0.343. So older versions also run into issues.

[Charles-Gagnon]

So you're saying that the newer webjobs package then did cause the break with the net7 stuff we've been seeing? Do you know exactly what happened to cause that?

[MaddyDev]

So you're saying that the newer webjobs package then did cause the break with the net7 stuff we've been seeing? Do you know exactly what happened to cause that?

No, that update didn't cause the net7 issue (tested it downgrading the package and still running into the same issue) but could potentially cause issues if we are not aligning and @fabiocav said it's best practice to align the worker with the web jobs instead of giving a range. To address that I made this change.

[Charles-Gagnon]

Won't that mean that every time they release a new webjobs version we have to first release a new version of our extension package, and then after that's published generate and release a new version of the worker package? That was what we were trying to avoid by doing this IIRC.

Do webjobs not follow sematic versioning guidelines? The idea we had is that we were still tied to the major version, so any breaking changes should be a new major version.

[MaddyDev]

Won't that mean that every time they release a new webjobs version we have to first release a new version of our extension package, and then after that's published generate and release a new version of the worker package? That was what we were trying to avoid by doing this IIRC.

Do webjobs not follow sematic versioning guidelines? The idea we had is that we were still tied to the major version, so any breaking changes should be a new major version.

Won't that mean that every time they release a new webjobs version we have to first release a new version of our extension package, and then after that's published generate and release a new version of the worker package? That was what we were trying to avoid by doing this IIRC.

Do webjobs not follow sematic versioning guidelines? The idea we had is that we were still tied to the major version, so any breaking changes should be a new major version.

Am not aware of that, as far as I remember we didn't want to release worker with every webjobs release even when there are no changes in it. @fabiocav Can you clarify if the above is needed.

[MaddyDev]

So you're saying that the newer webjobs package then did cause the break with the net7 stuff we've been seeing? Do you know exactly what happened to cause that?

No, that update didn't cause the net7 issue (tested it downgrading the package and still running into the same issue) but could potentially cause issues if we are not aligning and @fabiocav said it's best practice to align the worker with the web jobs instead of giving a range. To address that I made this change.

on Friday we did realize that the package bumps (System.Runtime.Caching) did break our package. When we're deciding of version bump, we didn't realize there is a breaking change and didn't bump preview package version since no new functionality/changes were introduced except the package bumps.

[Charles-Gagnon]

Please make an issue to track figuring out what the best way to handle the version is. It'd be great not to have to release a new version of the worker package every time we make a small fix in the main extension package.

[MaddyDev]

Please make an issue to track figuring out what the best way to handle the version is. It'd be great not to have to release a new version of the worker package every time we make a small fix in the main extension package.

#932 for tracking the best way to handle the version.