>* the next release will be 1.3.0 and require .NET 2.0 or better > > I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0, > Mono < 2.0, SSCLI and CLI 1.0 frameworks
That's even worth a +2! ;-) >* the main assembly will get a new name like log4net-13.dll, only be > signed by the new key > >* we provide two assemblies named log4net.dll signed with the old and > new key respecitvely that contain type forwards to the new assembly > only I'm afraid that I can't quite grasp all the stuff we could break. We should definitely work out every possible usecase we may break. We have messed enough and should try to not raise the tempers even more. > >stuff we haven't talked about, yet: > >* I'd like to split log4net-13.dll so that the main assembly can be used > for the client profile and a separate assembly contains the stuff that > requires System.Web - this way we no longer need the -cp builds. The client profile was dropped with .NET 4.5 and previous versions are automatically upgraded to include the missing DLLs once somebody runs an update. Thus I'm not sure if we should really split the library and double the required efforts. It's documented which features are not available when using log4net with the Client profile and maybe we could improve log4net's internal logging to reflect broken things caused by a missing System.Web.dll. >* add support for Mono 4.0 > > Actually I currently can only build Mono 2.0 and 4.0 and 2.0 will be > gone once I replace my really old home machine. I guess I need to > investigate running separate Mono installations in parallel. *cough* automated builds *cough* >* .NET 4.5? Is there anything special about 4.5 or does the 4.0 version > just work? Nothing special as far as I know, but as noted above they finally have dropped that bloody client profile. >* give the user list a heads up so they know about our plans and can > tell us to stop if necessary. Of course. Involve them as much as possible.
