>> Have you got an environment where you can build the 1.x and compact framework assemblies (right now I don't)? I could at one point a few years back, but probably not now. I was referring more to just being able to get the source from the tree. (For me getting anything SubVersion related working is a BIG step). :-) That was part my question about duplicating effort. If changes need to be made to get an environment that supports building, there is no need for multiple people to tackle it at once.
In the past I converted the zipped source to VS 2010 keeping the 2.0 framework target and made that work, but I did not work on tests etc., so I don't know how valid my efforts were. >> just as an alternative distribution in addition to one signed with the new non-secret key? Yes, both versions. I think that is necessary to keep the 3rd party people running until they have time to switch to the new non-secret key. >> Otherwise 1.2.11 is long overdue anyway Yes, I agree, that is way I was suggesting doing the "minimum" which is basically integrating the currently supplied/tested/gold fixes and features (such as the log file renaming feature-fix). Feature requests and fixes that need work go into the 4.0 build tree (and the refactored 3.5 build tree which was my step 4). This approach should allow for an "easy" (not hardly) production of the 1.2.11 that would be a drop in for anyone on 1.2.10 with the fixes/features that have been tested. Maybe we have to revisit the bug/feature list and produce 1.2.12 with the next round before going on to 2.0 tree with less frameworks. Once we do the 2.0 tree the 1.2.xx tree is frozen and we have less to maintain because we do not have to worry about 1.0, 1.1, compact etc. To sum up this paragraph, we produce a new stable long life span product (1.2.11 or 1.2.12) that people who do not wish to/cannot move forward can use for a long time to come. >> 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? Yes, fewer assemblies in the distribution. No great effort to be expended in removing the old code, but if you happen to be in the area, you could delete it just to clean up the code base, and we certainly would not have to worry about it breaking. We may not need this step. Again a poll question "Does anyone need xx,xy,xz... framework support?" If not, we skip it and move to the 4.0 or 3.5 tree as dictated by the poll. ---------------------------------------------------------------------- Roy Chastain -----Original Message----- From: Stefan Bodewig [mailto:[email protected]] Sent: Friday, August 12, 2011 13:20 To: [email protected] Subject: Re: Moving forward with updates, builds and versions 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
