Schedule for stable v2.0.0?

[sam31897]

Hi RazorLight team,

I am currently planning to use this library to create html reports for my company. However, I need a stable v2.0.0 version. I can not use v1.1.0 because the project will be in netstandard2.0.

Thanks,
sam31897

[jzabroski]

@sam31897 I saw this question, and was hoping to provide an update after the latest release. That said, what exactly does "stable" mean to you? No changing public APIs? I've been thinking about this question lately, because, technically, we broke binary compatibility in beta2 when we introduced Microsoft.AspNetCore.App FrameworkReference, which I am now reverting. Previously, I did not think of such changes as potential binary compatibility issues, but these are likely the largest source of instability RazorLight has, as opposed to the API itself.

[sam31897]

We're just looking for a release marked as stable be you guys. As of right now, the latest stable version i see is v1.10

[jzabroski]

OK, I get that. Trying to solve #360 and then should be good.

[jzabroski]

Need to resolve this and merge #400 and we should be good to go for 2.0.0.

It would be great if someone could also help tackle #371

[jzabroski]

@sam31897 I am going to try to release a stable this month.

[304NotModified]

Polite bump!

[jzabroski]

Hi Julian @304NotModified ,

I lost some momentum contributing to this project when @toddams appeared to re-new interest in it - I didn't want to step on his toes. I'm not exactly clear what the next steps should be, although I do have a strong grasp on why people are complaining about having to include AspNet SDK on the machine that runs RazorLight2.0.0-rc.3 and what the remaining trade-offs are to get a final version published.

[304NotModified]

Would be great if there would be a 2.0 RTM!

[tebeco]

I think we could roll a 2.0.0 without having to remove the FrameworkReference on Msft.Anc.App YET.
and Adress that later

I took a look at the linked PR to see if help was possible, but i noticed that it introduce undesired side effect / version downgrade ... with package that are supposed to be part of FrameworkReference. It seems that the PR try to force soem package to be using 2.2.0

• it's not release as package anymore because it's not netstandard anymore
• 2.2.0 is definitly not the latest version (it's quite old, december 2018)
• 2.1.x are probably more up to date and have less CVE than 2.2.0
• Msft.Anc.* 2.1 reached end of life (on Core Runtime) August 21, 2021 (which cancel the possible idea of using 2.1.x)
• 2.2 reached end of life December, 2019 <== CVE since then
• 3.0 reached end of life march 2020

Also taking in account all consumer using this package in application that does run on netcoreapp3.1/net6.0 (which are LTS / GoLive + LTS) or net5.0
Forcing a package downgrade on these package might have unwanted behavior. Especially if you try to consume any API introduced/changed since 3.0 (~September 2019)

A PR could for example create 2 project + sharing source in that repo

• RazorLight
• RazorLight.Slim
• create a Shared folder
  • with only .cs
  • no csproj (so that it does not polute dependency tree)
• each project include sources from either globbing pattern in respective csproj or manually

You can find a working example here for SignalR:
cs files:
https://github.com/dotnet/aspnetcore/tree/main/src/SignalR/common/Shared

referencing files:
https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/Http.Connections/src/Microsoft.AspNetCore.Http.Connections.csproj#L12-L20

Settings up path / variables:
https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/Directory.Build.props#L4-L7

Other usages in code:
https://github.com/search?q=org%3Adotnet+SignalRSharedSourceRoot&type=code

[jzabroski]

@tebeco Would you like to submit your own PR?

I looked through your comments in that PR and agree with them.

[tebeco]

I was gonna post a super long answer explaining how we all know how open source works
Gonna drop a PR to

• get TFM updated (ns2.0 + netcoreapp3.1/net5)
• will see if possible to bump dependencies too
• release 2.0.0 on that

NON GOAL:

• removing the FrameworkReference

POSSIBLE:
Another PR, trying to get a skeleton for the duplicated package so that anyone whiling to tackle the shrinking will be able to work on it
My idea here is that ...

• right know I don't need track 60MB on current disk/deployment/artifact
• I don't have much time
• I'd love to see people interested to take time just like @Aledever4i did (without the side effect that were in the PR)

I'd rather let that package continue it release train, and not block anyone else using the package

[jzabroski]

I was gonna post a super long answer explaining how we all know how open source works

I generally ask people if they want to contribute, as its a good way to get people involved: sometimes simply just asking helps push open source forward. As my pastor quotes, "You don't have because you don't ask." :D

NON GOAL:

• removing the FrameworkReference

I don't think it's even possible to remove the FrameworkReference. The nuget packages in the AspNetCore prefix were removed from nuget.org by Microsoft with the introduction of FrameworkReference. The only way I know to trim deployment now is to use a self-contained deployment and opt-in to assembly trimming features which are not even stable yet. I don't really like what Microsoft did, but it is what it is.

A PR could for example create 2 project + sharing source in that repo

I wish the new SDK Common Project System (CPS) project structure supported Xamarin Shared Asset Projects. cf https://github.com/xamarin/mobile-samples/tree/master/Tasky/TaskySharedCode - https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/intro.md mentions that Shard Projects were supposed to be part of CPS, but as far as I am aware, we're still waiting. (If I missed something, let me know).

[tebeco]

The only way I know to trim deployment now is to use a self-contained deployment and opt-in to assembly trimming features which are not even stable yet.

exactly and it’s up to consumer to do that right now. not library owner AFAIK. It’s not ideal I agree but you can’t decide what to trim as a library author … because transitive
unless the transitive are built FOR AOT, just like what MessagePack-Csharp did allowing you to consume as a submodule + build from source + changing it namespacing so that it does not conflict consumer that would use the library with another version

I wish the new SDK Common Project System (CPS) project structure supported Xamarin Shared Asset Projects ….

what i linked for signalr would basically do that, it’s manual though

That’s really the reason why i will probably just bump the TFM and the dependencies
then if someone show up whilling to do the implementation without the frameworkreference i’ll make the skeleton

i don’t plan to do the extra job if no one is going to implement it.
That’s a bit selfish of me but as said, we all know how open source work.

[tebeco]

@jzabroski is there a breaking change label or something to look out for when doing updates ?
eg:
for anyone upgrading 1.1.x to 2.0, what issue / PR should we open to get a sort of "release note" of what would potentially break