Skip to content
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

Closed
2 tasks
Anipik opened this issue Nov 15, 2019 · 17 comments
Closed
2 tasks

Infrastructure work required to service 5.0 #31505

Anipik opened this issue Nov 15, 2019 · 17 comments

Comments

@Anipik
Copy link
Contributor

Anipik commented Nov 15, 2019

We are making a lot of infra changes which will require changes in the servicing protocals. This issue is to track that work.

  • We have a centralized place for package verison, we will have to find a place of individuals packages to update that version in servicing
  • We have a centeralized place for assembly Verision, we will have to find a way to increment the assembly version for specific assemblies in servicing.

cc @ericstj @ViktorHofer @wtgodbe @safern @danmosemsft

@ViktorHofer
Copy link
Member

@Anipik can you please elaborate? Isn't setting the PackageVersion and AssemblyVersion in a leafs Directory.Build.props file sufficient?

@Anipik
Copy link
Contributor Author

Anipik commented Nov 15, 2019

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.

@ViktorHofer
Copy link
Member

The obvious answer for me would be:

  • Change an individual package's version: Set these properties in the leafs Directory.Build.props
  • Change all minor/patch versions: Change the property in Versions.props.

Trying to understand your ask better. What are the requirements for servicing in regards to package and assembly versions?

@safern
Copy link
Member

safern commented Nov 20, 2019

Shouldn't we just have global properties for those and then when servicing an individual package/assembly, just override it in the project Directory.Build.props? That's what we do now.

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.

@ericstj
Copy link
Member

ericstj commented Nov 20, 2019

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.

@ericstj
Copy link
Member

ericstj commented Dec 12, 2019

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.

@ViktorHofer
Copy link
Member

I don't think was being considered when the MajorVersion, MinorVersion, PatchVersion transformation logic to AssemblyVersion in Arcade was being written. I guess we want to set an AssemblyVersion property manually for ReferenceAssemblies to $(MajorVersion).$(MinorVersion).0. Does that sound right?

@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@ericstj ericstj removed the untriaged New issue has not been triaged by the area owner label Mar 14, 2020
@ericstj ericstj added this to the 5.0 milestone Mar 14, 2020
@ericstj
Copy link
Member

ericstj commented Mar 14, 2020

@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

@joperezr
Copy link
Member

Perhaps for any project that targets NETFramework it's assembly version bumps in servicing

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 Anipik modified the milestones: 5.0.0, Future Jul 9, 2020
@ViktorHofer
Copy link
Member

@Anipik the title links to 5.0 servicing. Should we move the milestone back? Do you know what the remaining work here is?

@Anipik Anipik modified the milestones: Future, 5.0.0 Oct 5, 2020
@Anipik
Copy link
Contributor Author

Anipik commented Oct 5, 2020

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

  1. Package Version rev ups
  2. Assembly Version rev ups and pinning of assembly version for ref assemblies
  3. A check to verify we are actually building and shipping the package we are changing.

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.

@ViktorHofer
Copy link
Member

Sounds good. I assigned you to the issue.

@ViktorHofer
Copy link
Member

@Anipik pls prioritize this work item over pre6.0 work. We are showing up high on Jeff's table 🗡️

@Anipik Anipik modified the milestones: 5.0.0, 5.0.X Oct 7, 2020
@Anipik
Copy link
Contributor Author

Anipik commented Oct 7, 2020

@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)

@ericstj
Copy link
Member

ericstj commented Oct 7, 2020

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.

@ViktorHofer ViktorHofer added this to Servicing in Infrastructure Backlog Feb 17, 2021
@ViktorHofer
Copy link
Member

@Anipik what's left to do here? I believe anything necessary to service 5.0 for next ~11 months should already be in place?

@Anipik
Copy link
Contributor Author

Anipik commented Feb 19, 2021

yes we can close this one

@Anipik Anipik closed this as completed Feb 19, 2021
Infrastructure Backlog automation moved this from Servicing to Done (in 6.0.0) Feb 19, 2021
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Mar 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants