I have finally gotten an environment allows me to get source etc. My questions are of the following types 1) - Do we have a plan? 2) - How do we prevent duplication of effort? 3) - Someone mentioned a poll. I would be glad to setup a survey on my SharePoint site. I hope the points below are a starting point for developing the questions to put into the survey.
I have seen the discussions on public vs. private signing key. I second the idea of switching to a publicly usable key, but maintain the private key for a "release" build so that the 3rd party vendors have something to reference. I am sure that some of them will require strongly names assemblies. I have seen the discussion on our first steps, but I have not observed a consensus. I would lay out the following as our steps. 1) - Produce the 1.2.11 build with all currently available fixes. Signed with the old key and all the current platforms. 2) - Move to a 2.0 build tree that drops support for .NET 1.0, 1.1, Compact etc. Produce a release with the same fixes as the 1.2.11 build and sign with the old private key. 3) - Start the 4.0 build tree (match the framework level) which targets the 4.0 Framework and is refactored so that it can run with a Client only framework when the non-Client support namespaces are not required by the application or requested appender. (2 DLLs). This gets signed with the private key and the new public key (2 distribution packages.) This version will support 4.0 and up only. (MONO if needed??) 4) - Apply the same refactoring to the 2.0 build tree to allow targeting the 3.5 Client install. (I believe this is a lower priority than the 4.0 simply because I do not believe that many people have attempted deployment with the 3.5 client set. (I could easily be wrong.) ---------------------------------------------------------------------- Roy Chastain
