New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infrastructure work required to service 5.0 #31505
Comments
@Anipik can you please elaborate? Isn't setting the PackageVersion and AssemblyVersion in a leafs Directory.Build.props file sufficient? |
Yes, that is the easier fix. We made a lot of effort to remove these stuff from Directory.Build.Props and have a centeralized place to describe these versions. I wanted to discuss if there any other better solutions for incrementing these versions in the servicing. |
The obvious answer for me would be:
Trying to understand your ask better. What are the requirements for servicing in regards to package and assembly versions? |
Shouldn't we just have global properties for those and then when servicing an individual package/assembly, just override it in the project We already have a centralized package version set globally and we just override it directly in the project if we need to bump just that package for servicing. |
We need to think through the scenarios and document what the process should be. Think of this like servicing readiness. I'm certain there will be multiple differences from 3.x. |
Wanted to reiterate my concern that motivated an issue. We need to make sure that central changes in servicing don't impact reference assembly versions. So a 5.0.n build should not produce different reference assembly versions over 5.0.0. |
I don't think was being considered when the |
@ViktorHofer that sounds right. We then manually rev AssemblyVersions when we need to patch packages that require a change. I wonder if we can codify that rule 🤔 . Perhaps for any project that targets NETFramework it's assembly version bumps in servicing. Then we go through and make sure every library that supports NETFramework has a NETFramework target? @joperezr |
I'm not sure I follow why we would do this every time. Is it because of the concern that the assembly could be GACed? If we are only bug fixing one small thing in an assembly, doing this will introduce the possiblity of requiring BindingRedirects on the app which a lot of people want to avoid. |
@Anipik the title links to 5.0 servicing. Should we move the milestone back? Do you know what the remaining work here is? |
I moved it back to 5.0. I want to see if we can automize the following
we have hit errors in the past where we have missed some cases during the review. The error rate is low for last few releases but its still dependent on manual review. Most of the people are not aware of these servicing nitpicks. |
Sounds good. I assigned you to the issue. |
@Anipik pls prioritize this work item over pre6.0 work. We are showing up high on Jeff's table 🗡️ |
i moved it to 5.0.X (Talked with @danmosemsft about creating this new one) |
I chatted with Jeff about this on Monday so he's aware. 5.0.x seems reasonable, I'll make sure he knows about that so it stays out of the query. |
@Anipik what's left to do here? I believe anything necessary to service 5.0 for next ~11 months should already be in place? |
yes we can close this one |
We are making a lot of infra changes which will require changes in the servicing protocals. This issue is to track that work.
cc @ericstj @ViktorHofer @wtgodbe @safern @danmosemsft
The text was updated successfully, but these errors were encountered: