logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Compilation Symbols
Date Mon, 05 Sep 2011 09:42:06 GMT
On 2011-08-21, Roy Chastain wrote:

> We must have "many" conditionals. As you noted 2.0 is not a superset of
> 1.1 and 4.0 is not a superset of 2.0. Because of CAS and other issues,
> 2.0 and 4.0 may be in direct opposition.


> 3.0 and 3.5 are indeed supersets of 2.0, but I doubt their importance as
> conditionals.  I would only see them as important IFF (if and only if)
> we do release a 3.5 targeted framework WITH a WCF appender.  I think the
> introduction of 3.5 as a tag should wait until later IFF we discover
> there is enough demand for a 3.5 target.

> I think that I like the idea of 4_0 and 4_0_FULL.  (Allow 4_0_COMPACT to
> be represented as !4_0_FULL.  So any 4_0 specific code that is not
> compact vs. full conditioned is under 4_0 and if it is only full it is
> under 4_0_FULL and it if is compact only it is under !4_0_FULL. I fear
> that NETCP will complicate things as we move from the 1.0/1.1 compact to
> the 4.0 compact and potentially to a 3.5 compact if that is necessary in
> the future.  (Right now, the 3.5 compact COULD be considered a 2.0
> compact.  Yes, you must target 3.5 to get the choice of compact, but you
> do not have to take advantage of 3.5 specific code.)

> I would further say that any code that works in 2.0 and 4.0 has NO
> conditionals around it, but not include compatibility with 1.0/1.1 as a
> requirement for no conditional. To elaborate, the 2_0 tag becomes 2_0
> specific code.  (Code that does not work in 4.0.)  Any 2.0 code that
> does not work in 1.0/1.1 becomes !1_0

Going forward I pretty much agree with you - but then again we may not
need to think about 1.x and compact framework at all then 8-)

For the 1.2.x branch I'd prefer to stick with the current approach in
order to minimize code changes.

> Other than MONO I do not believe the family concept will serve us going
> into the future.  What I am really saying is that the base code will
> favor 2.0/4.0 of the framework and anything that differs from that
> requires a conditional.

I'm not even convinced we'll need much Mono specific code at all -
outside of appenders, maybe.  Buth then again I must admit that there
are quite a few parts of trunk that I never really looked into, so I may
be wrong.

> This idea is probably not in keeping with the original concept, but the
> framework has grown well beyond what was envisioned when the project
> started and we might need to adjust our thinking to match.



View raw message