On 2011-08-12, Roy Chastain wrote: > I have finally gotten an environment allows me to get source etc.
Great. Have you got an environemt where you can build the 1.x and compact framework assemblies (right now I don't)? SSCLI? > My questions are of the following types > 1) - Do we have a plan? Not yet. 8-) Your list matches my ideas pretty well. > 2) - How do we prevent duplication of effort? This list, wiki, JIRA. Right now it doesn't look to me as if we had so many people that we could lose track. Short term we'll be slowed down by the fact that there are only very few people with write access to the source tree, of course. > 3) - Someone mentioned a poll. I would be glad to setup a survey on my > SharePoint site. Thanks. > 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. You mean you'd still want to use a secret key for "release" in either case or just as an alternative distribution in addition to one signed with the new non-secret key? > 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. +1 I'd suggest we triage JIRA to see whether there are any open issues that (1) are bugs and not feature requests, (2) come with tests that fail and (3) come with a patch that makes the test pass. If there are any such issues they could go into 1.2.11 IMHO. Otherwise 1.2.11 is long overdue anyway. > 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. How would that be different from the first step - except that we'd distribute fewer assemblies in the binary distribution? Do you plan to remove all 1.0/1.1 specific code and the conditional compilations for NET 2.0 so that this release actually used different source code? > 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. Totally agreed that this is needed. I'd poll for 3.5 support as well. > (MONO if needed??) Mono is at the 4.0 level in many things and not even at 3.5 in others. For the things log4net currently uses it should work fine AFAICT. > 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.) Should have read to the end before I started typing ;-) I'd prioritize your steps 3 and 4 with the help of a poll among users to see how urgently 3.5 support is needed. I agree I have seen way more questions about 4.0 than 3.5, though. Stefan
