Roy, I had submitted a patch about building log4net for 2010 (.NET 4 Client profile and .NET 4) which also fixes an issue in the UdpAppender.
https://issues.apache.org/jira/browse/LOG4NET-296 I'd be really glad to see this working and I could help in any direction needed. Regards Tasos Vogiatzoglou On Fri, Aug 12, 2011 at 8:40 PM, Roy Chastain <r...@roychastain.org> wrote: >>> 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:bode...@apache.org] > Sent: Friday, August 12, 2011 13:20 > To: log4net-dev@logging.apache.org > 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 >
