search

YUICompressor-NET / YUICompressor.NET

Port of Yahoo!'s Java YUICompressor to .NET
BSD 3-Clause "New" or "Revised" License
122 stars 61 forks source link

Multitarget project to .NET Standard 1.2 (.NET 4.5.2 compat) and .NET Standard 2.0 #22

Closed PureKrome closed 6 years ago

PureKrome commented 7 years ago

Some people don't have .NET 2.0 installed anymore.

PureKrome commented 7 years ago

Which version of the framework?

cc @freeranger

Taritsyn commented 7 years ago

I think that need to support the following versions: .NET 4.0 (.NET 4.0 Client Profile for Yahoo.Yui.Compressor.dll) and .NET 4.5.

freeranger commented 7 years ago

I've only seen one person complain about .NET 2. Currently supported versions of the framework are 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2 so arguably you shouldn't go to 4.0 or 4.5 for that matter. What about just going to 3.5 which is still supported? No point excluding users unnecessarily and we aren't using any features that need an upgrade to 4.anything

Taritsyn commented 7 years ago

Without support of .NET 4.0, YUICompressor.NET may lose a large number of users.

PureKrome commented 7 years ago

@freeranger the issue is not the PACKAGE/dll itself. The issue about contributor-takeup.

for example ->

of course a .net 2.0 compat dll will work with .net 2+ projects... but that's not the problem.

4.0 was released on 2010-04-12 with VS2010 ... so that chances that people are going to be working with that are slim. You would like to assume the majority are either 2012/13 or 2015.

I'd like to target 4.5.0 personally. That's targetting a Windows 8 machine with VS2012 installed as a baseline.

ref: https://en.wikipedia.org/wiki/.NET_Framework

freeranger commented 7 years ago

If you go to 4.anything then you rule out for example building on a vanilla Windows Server 2008 R2 (or indeed Windows 7 PC) which comes with 3.5 by default. In corporate environments there are a lot of 2008 servers still out there so if you build on a CI server running 2008 then you are screwed unless you install 4.something just to support YUI. This is exactly what we build on at the moment where I work.

I don't see what targeting 4.5 gives us beyond forcing people to upgrade (very hard in corporate environments) or forcing them to stick with an older version of the library (@taritsyn, this is a "solution" for you too if we did go to 4.5). Since we are not using any features later than 2.0, there is nothing to gain by introducing this pain.

Ok you might choose to drop support for 2.0 if it is no longer supported (perhaps this is the case?) or because it is not installed on some vanilla machines, but I don't think you can say the same for 3.5

We should go with the lowest version that has the widest support unless we need specific features in later environments - so my vote would be 3.5

In the corporate where I work currently, every new developer PC comes with Windows 7, which is only available in about the last 12 months - as I said earlier, corporates are very slow to roll out new versions of operating systems (about 1/2 our servers are 2008, 1/2 2012, plus a handful of 2003 ones which granted are being decommissioned) because of the sheer number of machines they need to support and the sheer number of applications they need to support, security checking they need to do etc.

I am a consultant, not an employee, so have worked at a large number of companies over the last 15 years and it's the same story everywhere about the speed of upgrade.

Having said all that, it's your project so up to you ultimately what you do with it....

PureKrome commented 7 years ago

Lets check the stats...

image

source

oh fk a duck :(

i honestly thought win7 would be soooo much lower. FML.

Hm. ok, I'm not going to bother changing it then. I refuse to install .NET < 4 on my machine So i'll just leave this issue open until win7 drops off in a few years time.

(i also don't have any vm stuff installed, nor do I want to)

Sweet :) np at all :) Glad you mentioned it!

freeranger commented 7 years ago

What would be useful is being able to target multiple framework versions so we could target .NET Core/.Net Standard too, then we could keep support for 2.0, 4.0, 4.latest and be portable too.

trullock commented 6 years ago

I'm happy to work on this, can we make some decisions on what we want to support and I'll try and make it happen

freeranger commented 6 years ago

@trullock If we go with multi targeting support, what's the lowest version of .NETStandard and .NETFramework you think we can support? It seems to me that framework 2, 4.6.1 and the lowest version of standard possible would be the way to go. Thoughts?

trullock commented 6 years ago

ES.Net 2.0 targets only net45 and netstandard2, not that this can't be changed. I suggest we start there and it can be expanded with further PRs

PureKrome commented 6 years ago

👋 Hi all! Just jumping back into the thread again.

How about targeting:

NET.4.5.1 stopped support so the min is now 4.5.2.

So is it worth even targeting NET45 instead of just going straight to 452? I know @freeranger (back in 2016) said he was stuck with old OS's and enterprises are stuck with them. But for me, we have the existing library up on NuGet that is working fine for them. These enterprises also don't need to upgrade to the soon-to-be-newer-released version, so part of me thinks: meh @ them! I can see the argument for: target the lowest you need. But a part of me is also: target the lowest supported .NET Framework and let old systems remain untouched.

TL;DR;

That's my thoughts.

freeranger commented 6 years ago

@PureKrome agreed it should be the lowest supported version - trouble is, lower versions are still supported on some platforms ;) As you say though, people can use the older version of the library if need be.

Re: the versions to support, Microsoft guidance is to target the lowest version of Standard you can: https://docs.microsoft.com/en-us/dotnet/standard/net-standard and framework 452 will only support 1.2 so my vote would be for those two versions. If it turns out that a higher NetStandard version is needed then you will need to support three versions - 452, the Standard version you want, and the framework version that supports that standard

PureKrome commented 6 years ago

trouble is, lower versions are still supported on some platforms ;)

I also thought that the support was for everything. meaning, if you're on 2008 then no .NET was pre-installed. 2012 it came preinstalled with 45, 2012R2 with 451 ... and therefore, you are still not getting support for the .NET side of things. Reference.

Anyways, we're on the same page, so lets lock it down and make the call:

winner winner chicken dinner!

trullock commented 6 years ago

@PureKrome I agree entirely, does this mean you need to bump EcmaScript.net to 452 also? And if so, please do :)

PureKrome commented 6 years ago

~Doh, yes!~

~ES doesn't get a release for 10000 years, then gets 2 in 1 week. GG @purekrome~ 😊

PureKrome commented 6 years ago

Actually @trullock - i'm going through a quick spike (locally) and I didn't have to update ES.NET because if I make YUIC.NET NS2.0/NET462 .. this means the 462 target can use any library that's <=462. ES2 is NS20 + NET45 .. so it's less that 462 .. so I can use :)

Now .. I'm looking at these 2 projects:

and have some problems. Firstly, is there anyone maybe using the .NAnt version? Does anyone use Nant? Anyways, i upgrade that one easily. Just curious if Nant is dead.

Secondly - Yahoo.Yui.Compressor.Web.Optimization. This is old ... very old. And it's got some dependencies on .NET Framework's System.Web which is part of the many reasons for .NET Core to be born.

So ... I'm not sure how to migrate this to NS20. So my real question is: is this even needed these days? Is this relevant?

I can understand maybe the MSBuild task ...

Some stats:

So the difference between the main library and the rest is .. huge. Nant is like .. meh, negligible (but the update was easy-as).

But for YUICompressor.NET.Web.Optimization I'm thinking maybe we should not bother with uping that and just let people use the current one in their old systems. Think about it -> if a person is going to go 'new-and-shiney' they wouldn't be using this, anyways. There are better tools, now.

But there seems to be some people using the main repo ... possibly, still. So that can get up'd.

Thoughts?

EDIT:

trullock commented 6 years ago

Yeah sorry, hadn't had my coffee when I wrote that.

I'm biased here because my use case is the main DLL directly, i dont use any of the tasks.

I still share the opinion from earlier, update with minimal legacy support, the old nuget still exists (lets make this clear in the docs). If and when people need these ancient things porting, thats what PRs are for.

Progress!

PureKrome commented 6 years ago

I'm biased here because my use case is the main DLL directly, i dont use any of the tasks.

Brilliant :) and this is what the stats are suggesting - most people are using the main dll instead of the other ones.

PureKrome commented 6 years ago

Branch with changes is now up for a quick squiz.

I'm not PR'ing just yet until some of the discussion re the Web.Optimization is locked down. My thoughts are: trash it for this version and have a reference to the nuget in a readme and have a BRANCH made available that is for easy archival/research purposes.

freeranger commented 6 years ago

I would keep the main one (obviously!) and the msbuild tasks and retire the rest. MSBuild is definitely a legit use - I'm surprised it isn't higher actually. Anyone using NANT still gets what they deserve :D They can use the current major version we have out there - you will have to bump the major version anyway for the proposed changes. All we need to do is make it clear in the docs that NANT and optimisation support stop at version XXX

Alternatively, you don't have to make a Core version of everything - WebOptimizations could target just the framework if you wanted to. Whilst it is nice for everything to target everything, it is not mandatory....

trullock commented 6 years ago

I think this is reasonable

trullock commented 6 years ago

Keep old version up Update docs saying whats what Support modern stuff only until someone sends you a PR ;)

PureKrome commented 6 years ago

Added a TAG for future reference / archiving / referencing.

image

PureKrome commented 6 years ago

Now fixed/resolved with #33 .