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.
Agreed. > 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. +1 Stefan
