On Aug 11, 2011, at 12:16 AM, Stefan Bodewig wrote:
> 
> Right now I'd lean towards making breaking changes for a 1.3.x line of
> releases and using the new key there, I'm not sure whether signing those
> with the old key would be useful at all.

The following email describes a situation where a new log4net signed with the 
existing key would be very handy. We'd need to nuance the message so that most 
people who don't have a need for the drop in compatible old-key signed 
assemblies link against the new key signed binaries.

If we are disclosing the a common unsecret key, then the need to address every 
platform nuance is much reduced and we can just direct someone who needs a 
build for a specific variant of .NET or Mono to build it themselves.

It may be premature, but if someone wants to up some sort of poll to determine 
which variants to try to support and test, please take the initiative.




On Aug 9, 2011, at 12:27 AM, Lee Chun Kit wrote:

> On Tue, Aug 9, 2011 at 4:20 AM, Johannes Gustafsson <johanne...@gmail.com> 
> wrote:
> Hi,
> 
> There are a few bugfixes in the trunk that I need and since there has been no 
> new release for a very long time, I tried to compile it myself. I created a 
> key and have successfully compiled it with no problems. However, I have quite 
> a few 3rd party dependencies that themselves are dependent on log4net. These 
> dependencies can't find load the new assembly that I have created because 
> they require that it is signed with a key that I dont have access to. So this 
> means that I can't use my own version of log4net without recompiling all my 
> dependencies.
> 
> Do you have any suggestions to how I can solve this?
> 
> Regards,
> /Johannes
> 
> If your 3rd party dependencies don't require the bug fixes, you could 
> maintain two different references. Just a suggestion.

Reply via email to