For what it is worth, if you go to https://repository.apache.org/#central-stat <https://repository.apache.org/#central-stat> you can see that about 25% of the downloads for log4j-api are for versions that still support Java 6. Unfortunately, I don’t know of any way to detect how many users are still using Java 7 unless we can find a commons component that has a Java 7 and Java 8 version and look at those download stats. But if we have 1/4 or our users still on Java 6 I have to believe a larger number than that are using Java 7.
Ralph > On Aug 30, 2017, at 8:31 AM, Matt Sicker <boa...@gmail.com> wrote: > > Oh well, so much for that idea. Do you think net-2.0 is still in wide > enough use to continue supporting it? We moved on from Java 6 to 7 as > baseline requirements for Log4j a while back even though there are still > stragglers using 6, though the idea there is that most users still on 6 > aren't really updating anything anymore other than security patches if > applicable. Would you say it's similar in .net 2? > > On 30 August 2017 at 02:39, Dominik Psenner <dpsen...@gmail.com> wrote: > >> >> On 2017-08-29 16:12, Matt Sicker wrote: >> >>> I'm not too familiar with this area, but would using Windows containers >>> (e.g., via Docker or similar) work here? Or would that only support newer >>> versions of .net anyways? >>> >> >> Good idea Matt, unfortunately net-2.0 is not available in a windows server >> docker container as documented in the image variants section at >> https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer >> are available. We already build net-3.5, net-4.0 and net-4.5 with jenkins. >> I've the impression that if we changed this today, we would gain nothing. >> >> >> >>> On 28 August 2017 at 23:32, Dominik Psenner <dpsen...@gmail.com> wrote: >>> >>> Hi, >>>> >>>> Chris just resolved our infra ticket regarding .net frameworks on the >>>> windows nodes. This is a summary of the outcome: >>>> >>>> Chris Thistlethwaite resolved INFRA-14645. >>>>> ------------------------------------------ >>>>> Resolution: Fixed >>>>> >>>>>> 1. We have observed that none of the windows nodes appear to have >>>>>> >>>>> net-2.0 installed so we cannot build assemblies against it. Is it >>>> possible >>>> to install it on one or more of the windows nodes? It may well be the >>>> case >>>> that it is not possible to have .NET framework 2.0 installed when a newer >>>> .NET framework is installed on the same windows os. >>>> >>>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0 >>>>> >>>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd >>>> also >>>> argue that building for .Net 2 isn't something we can support if the >>>> tools >>>> at hand only allow newer binaries. >>>> >>>> To me this means that we can no longer build assemblies targeted against >>>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins. >>>> We'll >>>> have to announce this soon. >>>> >>>> 2. We have observed that windows-2012-3 does not have .NET framework 3.5 >>>>>> >>>>> installed while the other two Windows nodes have it installed. >>>> >>>> 2. jenkins-win2012-3 has been updated to fall in line with the other >>>>> >>>> nodes. >>>> >>>> This means we will no longer see intermittent build failures because of >>>> the >>>> missing framework. >>>> >>>> 3. As an improvement to the windows node labels we suggest to add >>>>>> >>>>> additional labels that match the installed .NET frameworks. Currently >>>> it is >>>> rather unclear what the windows nodes actually can do and it would >>>> further >>>> allow that not all windows nodes to have exactly the same components >>>> installed. (i.e. windows-2012-1 could have the labels "Windows", >>>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..) >>>> >>>> 3. Agreed, the windows nodes could use more organized labeling, however, >>>>> >>>> we're currently keeping them all built out the same (or as close as >>>> possible obviously) so we can maximize the few boxes we have. We just >>>> don't >>>> have enough need to run specific Windows configurations. >>>> >>>> Now that [2] is fixed, all windows nodes have the same capabilities and >>>> therefore this is not an issue. >>>> >>>> Cheers, >>>> Dominik >>>> >>>> >>> >>> >> > > > -- > Matt Sicker <boa...@gmail.com>
