Stop cascading version changes in servicing updates

Our policy since 1.0.0 has been to always cascade version updates in the packages we own. e.g. if Logging has a product change in 2.1.x, then Kestrel, EF Core, Mvc, etc also re-ship with the updated Logging dependency. This has been done for a variety of reasons:

NuGet does not show updates for transitive dependencies, only direct ones
NuGet does resolves the lowest compatible transitive dependencies
ASP.NET Core ships to both .NET Framework (where transitive dependency version matters) and .NET Core (where it matters less if you use the shared framework)

While transitive dependencies is still an important scenario, this practice of always patching has led to bigger issues.

High probability users will unintentionally upgrade out of the shared framework: #3307
Conflicts with metapackages that attempt to use exact version constraints: https://github.com/aspnet/Universe/issues/1180
A quality perception issue: the high volume of new versions in servicing updates with only metadata changes has created the impression that new versions of packages may not be very important. It's also made it appear like there are more issues product than there really are.
High volume of packages changing with only metadata changes. Of the last 301 packages published in a servicing update, only 11 contained actual changes to the implementation assemblies. (3.5%)

Proposal
Change 1
Stop cascading versions for every servicing patch.
For example, after 2.2.0 is finished, patching Logging to 2.2.1 would not necessarily mean Kestrel, Mvc, and SignalR need a 2.2.1 release.
Exceptions
This is the general rule, but there may arise important scenarios when the transitive version matters. When these occur, we will make manual updates. Examples may include:

security issues
high-impact functional changes in patches
(unlikely to happen -- in theory) API additions or changes in a patch

Implementation plan
We'll start by implementing this within ASP.NET Core on a repo by repo basis. Doing this from package to package within a repo is currently prohibitively expensive due to the way we use ProjectReference and nuspec generation.
Change 2
Work with NuGet to provide better tooling for finding and updating out of date transitive references. Some proposals currently in the incubation: https://github.com/NuGet/Home/issues/5762, https://github.com/NuGet/Home/issues/2867
Not changing
Metapackages, such as Microsoft.AspNetCore, AspNetCore.App, and AspNetCore.All will continue to cascade versions. These provide the best way for users to get the latest set of things, without hoisting dozens of transitive dependencies to be direct dependencies.
cc @DamianEdwards @davidfowl @Eilon @muratg

I dig this.

There are a lot of product changes going into 2.1.3 so there are still a decent number of packages in the next update, but this change in strategy reduces the packages shipping from 192 to 87. I sent mail examining the effects of this change.

You've put in quite some effort to make versioning easier/consistent in the .NET Core ecosystem so this would be a step back in my opinion. It makes updating dependencies much harder for projects that do not depend on a meta package. Right now, I can just easily replace all "2.1.1" packages with "2.1.2".
Will you "skip" version numbers when you patch a library that hasn't been patched in a previous servicing release?
Example: In ASP.NET Core 2.1.3, Microsoft.Extensions.Configuration will not be patched and stays on "2.1.2". However, in ASP.NET Core 2.1.4 it needs a patch - will it get "2.1.3" or "2.1.4" (and therefore skip a version)?
If you don't skip versions, it will result in a mess where nobody knows which assemblies belong to a certain servicing release. (Microsoft.Extensions.Configuration 2.1.3 belongs to ASP.NET Core 2.1.4 even and not ASP.NET Core 2.1.3)

While I agree the versioning consistency is maddening when not using a metapackage, I don't think this isn't going to make that problem better or worse. The current servicing strategy still leaves a jagged edge. For example, if you look at the dependencies of Microsoft.AspNetCore.App v2.1.2, you'll see that the latest versions of our packages are a mix of 2.1.0, 2.1.1, and 2.1.2.
Versioning consistency is something I don't think we can address in the 2.x timeframe, but it's one of the things I'd like to reconsider for 3.0.

thanks for your response @natemcmaster ! What do you think about my comment regarding "skipping" versions to at least ensure that any changed package has the same version as the meta package?

Sure, that's much less of an issue though than having to explain why Some.Package 2.1.3 does NOT belong to ASP.NET Core 2.1.3 but to e.g. 2.1.4
Anyway - just wanted to post my opinion. I can probably live with whatever you guys decide 😄.

This work was done in https://github.com/aspnet/Universe/pull/1257 and will be part of 2.1.3


Fix opening logo link in a new tab

Purpose

Describe the problems, issues, or needs driving this feature/fix and include links to related issues in the following format: Resolves issue1, issue2, etc.

Incorrect branch


Doesn't install on openSUSE

What happened?
Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Building wheels for collected packages: systemd-python
  Building wheel for systemd-python (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py bdist_wheel did not run successfully.
  │ exit code: 1
  ╰─> [24 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-cpython-311
      creating build/lib.linux-x86_64-cpython-311/systemd
      copying systemd/__init__.py -> build/lib.linux-x86_64-cpython-311/systemd
      copying systemd/journal.py -> build/lib.linux-x86_64-cpython-311/systemd
      copying systemd/daemon.py -> build/lib.linux-x86_64-cpython-311/systemd
      creating build/lib.linux-x86_64-cpython-311/systemd/test
      copying systemd/test/test_daemon.py -> build/lib.linux-x86_64-cpython-311/systemd/test
      copying systemd/test/test_journal.py -> build/lib.linux-x86_64-cpython-311/systemd/test
      copying systemd/test/test_login.py -> build/lib.linux-x86_64-cpython-311/systemd/test
      copying systemd/test/test_id128.py -> build/lib.linux-x86_64-cpython-311/systemd/test
      running build_ext
      building 'systemd/_journal' extension
      creating build/temp.linux-x86_64-cpython-311
      creating build/temp.linux-x86_64-cpython-311/systemd
      gcc -Wsign-compare -DNDEBUG -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -DOPENSSL_LOAD_CONF -fwrapv -fno-semantic-interposition -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -fPIC -DPACKAGE_VERSION=\"235\" -DLIBSYSTEMD_VERSION=254 -I/opt/yin-yang/.venv/include -I/usr/include/python3.11 -c systemd/_journal.c -o build/temp.linux-x86_64-cpython-311/systemd/_journal.o -std=c99 -Werror=implicit-function-declaration
      systemd/_journal.c:21:10: fatal error: Python.h: No such file or directory
         21 | #include <Python.h>
            |          ^~~~~~~~~~
      compilation terminated.
      error: command '/bin/gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for systemd-python
  Running setup.py clean for systemd-python
Failed to build systemd-python
ERROR: Could not build wheels for systemd-python, which is required to install pyproject.toml-based projects

Version
the one from the repo
How did you install Yin & Yang?
Git clone + running install script
What desktop environments are you seeing the problem on?
KDE
Which plugin causes the issue?
None
What software version do you use?
No response
Relevant log output
No response

Try to install systemd-python from your systems package manager.

I've had the same problem and I was able to solve it.
Not a bug, you just need to install some dependencies first.
I've started with python-systemd. I've found in in RPM.
Then I've installed pyside6
sudo zypper install python3-pyside6
and python3-devel
sudo zypper install python3-devel
After all the above, Yin-Yang installed successfully.

I will consider this as resolved then


publish is failing without change notes

az blueprint publish is failing when --change-notes are not supplied even though parameter is optional.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 82aa0874-eb79-9bed-f3fc-3a0e6d923c50
Version Independent ID: 1971ba1e-c071-587c-2673-70d0a659cc32
Content: az blueprint
Content Source: latest/docs-ref-autogen/ext/blueprint/blueprint.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@fengzhou-msft please take a look


Log of user emails

Button on Overview dashboard
Pops up a modal to display emails that can be filtered (valid members, officer, executives, non-valid members, everyone who is valid)
Useful for Blastweek emails

Note: Valid member = verified email + membership ongoing

can we filter emails without a modal?


Elide default parameter settings, add benchmarks

I added some benchmarking tests and then reduce the number of native synchronized calls.
For 100 chunks of 16 MB of (short) (rand.nextGaussian() * Short.MAX_VALUE/2048.0 + 255), I get the following results.
The test parameter pairs are {compression_level, number_of_threads}. Timings are for the entire AbstractN5Test suite. The traditional tests take about a second to run in total. The rest of the time is spent compressing the 100 chunks .
    	int m = Zstd.minCompressionLevel();
    	int M = Zstd.maxCompressionLevel();
    	System.out.println("Minimum compression level: " + m);
    	System.out.println("Maximum compression level: " + M);
    	//Comments below are with 16 MiB of int16 255 +/- 32;
		return Arrays.asList(new Object[][] {
			{ m,0}, { m,2}, { m,4}, { m,8}, // test  0 -  3, 100%,  3.5s, 1 thread
			{-2,0}, {-2,2}, {-2,4}, {-2,8}, // test  4 -  7,  97%,  4.5s, 1 thread
			{-1,0}, {-1,2}, {-1,4}, {-1,8}, // test  8 - 11,  96%,  5.0s, 8 threads
			//Compression level 0 means default (3)
			{ 1,0}, { 1,2}, { 1,4}, { 1,8}, // test 12 - 15,  55%,  5.5s, 8 threads
			{ 2,0}, { 2,2}, { 2,4}, { 2,8}, // test 16 - 19,  53%,  8.1s, 4 threads
			{ 3,0}, { 3,2}, { 3,4}, { 3,8}, // test 20 - 23,  51%, 14.0s, 4 threads
			{ 6,0}, { 6,2}, { 6,4}, { 6,8}, // test 24 - 27,  49%, 25.5s, 2 threads
			//{12,0}, {12,1}, {12,2}, {12,4}, // test 28 - 31
			//{15,0}, {15,1}, {15,2}, {15,4}, // test 32 - 35
			//{ M,8}, { M,1}, { M,2}, { M,4}  // test 36 - 39
		});

The effect of eliding unncessary native synchronized calls saved at most 100 ms.

After enabling the elision, I got the following timings. The effect is not great.
3.3s
4.5s
5.1s
5.5s
8.2s
13.9s
25.4s

@axtimwalde I'm going to push this through into FIJI so that it available as soon as possible.


Blog Article: Adopting Continuous Integration for Long-timescale Materials Simulation

The proposed blog article highlights a valuable collaboration between the IDEAS and EXAALT ECP project teams.  The goal of the collaboration was to help the EXAALT team adopt productive and sustainable software practices (with an emphasis on Continuous integration and Testing).
A draft of the article can be found at: https://github.com/rjzamora/ci-blog

Hi Rick -- Looks great; please transition into the BSSw blog area and then we'll move ahead with image treatment and copy edits.
blog area of repo:
https://github.com/betterscientificsoftware/betterscientificsoftware.github.io/tree/master/Articles/Blog
sample skeleton file for blog article:
https://github.com/betterscientificsoftware/betterscientificsoftware.github.io/blob/master/Articles/Blog/BlogArticleSkeletonA.md
Many thanks,
Lois

This is done: https://bssw.io/blog_posts/adopting-continuous-integration-for-long-timescale-materials-simulation


Stateful commands + small cache and performance changes

Stateful Commands
@ can be used to add a context to the prompt. e.g. @ec2 will implicitly prefix all commands with ec2. exit will remove the most recently added context.  See issue.
Cache and Performance
It used to be that every time the user did a tab completion, the autocompleter would have to do a full parse of the entire line. I made some changes on the condition for full parses such that only tab completions with arguments do a full parse.
Also, all_args are cached while there is no change in context.

Thanks for the pull request.  Quick note on the tests.  Looks like they're failing due to a recent change in prompt toolkit.  There's a fix out for this: https://github.com/awslabs/aws-shell/pull/137
Once that's merged, you would mind rebasing against master so you can pull in that change?  That should fix the failing tests.

@jamesls done!

I would love for this to be merged and released. Any reason this hasn't been merged?


Add antrea-interworking package

Signed-off-by: Wenqi Qiu<EMAIL_ADDRESS>What this PR does / why we need it
Add Antrea-interworking Package
Which issue(s) this PR fixes

Fixes: #
Describe testing done for PR
Special notes for your reviewer

Also, yaml and lint tests should pass


Conversion error, Jekyll 3.0.0

Jekyll 3 upgrade in progress and getting the following when compiling my coffeescript, same environment builds under version 2 latest.
  Conversion error: Jekyll::Converters::CoffeeScript encountered an error while converting 'js/app.coffee':
                    SyntaxError: [stdin]:1:48: unexpected number
compile ((execjs):6633:19): SyntaxError: [stdin]:1:48: unexpected number (ExecJS::RuntimeError)
	from eval (<anonymous>:1:10)
	from print ((execjs):6644:8)
	from (execjs):6650:14
	from require../helpers.exports ((execjs):1:102)
	from Object.<anonymous> ((execjs):1:120)
	from Module._compile (module.js:456:26)
	from Object.Module._extensions..js (module.js:474:10)
	from Module.load (module.js:356:32)
	from Function.Module._load (module.js:312:12)
	from Function.Module.runMain (module.js:497:10)
	from startup (node.js:119:16)
	from node.js:902:3
	from /var/lib/gems/2.1.0/gems/execjs-2.6.0/lib/execjs/external_runtime.rb:39:in `exec'
	from /var/lib/gems/2.1.0/gems/execjs-2.6.0/lib/execjs/external_runtime.rb:21:in `eval'
	from /var/lib/gems/2.1.0/gems/execjs-2.6.0/lib/execjs/external_runtime.rb:46:in `call'
	from /var/lib/gems/2.1.0/gems/coffee-script-2.4.1/lib/coffee_script.rb:78:in `compile'
	from /var/lib/gems/2.1.0/gems/jekyll-coffeescript-1.0.1/lib/jekyll/converters/coffeescript.rb:16:in `convert'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/convertible.rb:73:in `block in transform'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/convertible.rb:71:in `each'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/convertible.rb:71:in `reduce'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/convertible.rb:71:in `transform'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/convertible.rb:258:in `do_layout'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/page.rb:116:in `render'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/site.rb:179:in `block in render'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/site.rb:177:in `each'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/site.rb:177:in `render'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/site.rb:59:in `process'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/command.rb:28:in `process_site'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/commands/build.rb:60:in `build'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/commands/build.rb:35:in `process'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/lib/jekyll/commands/build.rb:18:in `block (2 levels) in init_with_program'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary/command.rb:220:in `call'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary/command.rb:220:in `block in execute'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary/command.rb:220:in `each'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary/command.rb:220:in `execute'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary/program.rb:42:in `go'
	from /var/lib/gems/2.1.0/gems/mercenary-0.3.5/lib/mercenary.rb:19:in `program'
	from /var/lib/gems/2.1.0/gems/jekyll-3.0.0/bin/jekyll:17:in `<top (required)>'
	from /usr/local/bin/jekyll:23:in `load'
	from /usr/local/bin/jekyll:23:in `<main>'

Seems to be related to using {% include... in the main coffeescript file

Error on my end, project uses a custom include tag (which I'd forgotten about) and due to changes in Jekyll's IncludeTag (tag_includes_dir -> resolved_includes_dir) it broke a bit.

Glad you got it fixed !


[feature] create nestjs Adapter

create nestjs Adapter

I believe this would belong in the discussions. Furthermore, I believe there already a few others trying to tackle building a Nestjs / Nextjs adapter?