I installed material-ui/lab: 4.0.0-alpha.60,
in my project, which is an alpha version that the Material-UI team doesn't recommend using in production projects.
I checked the versions here, but I didn't find anything other than the alpha version.
What is the official release of #material-ui/lab, or what alternative I can use instead of it?
Related
To my knowledge, the latest non-alpha version of the #ui5/cli and #sap/ux-ui5-tooling (as of 2nd March 2022 - version 2.14.6 and 1.5.0 respectively) are the ones to use.
However, I wanted to confirm as my organisation has multiple ui5 projects and so having a standardised version of the #ui5/cli and #sap/ux-ui5-tooling dependencies could prevent issues around bugs in tooling.
If the advice is just to use the latest non-alpha version, then I just need to update the dependencies regularly.
The versions you mentioned should be your choice to use in a productive environment.
The upcoming UI5 tooling 3.0 is not.
I don't think you will achieve the same version in every app because of the lifecycle.
The packages are fast paced and when u have a stable app deployed you will not update it every month I think.
I would not invest time to find the perfect tooling version.
I am trying to use pre-released versions of packages on Unity.
I followed some tutorials and guides, and from my understanding, I should check the "Enable pre-release packages" Check-box as I did here:
But still, when I go to the package manager, I don't see any newer version.
How do I fix it? I want to use the OnActionReceived(ActionBuffers actions) function, and on my current version, I cant use it.
I'm using the Unity version 2021.1.19f1
Thanks!
It's written in the documentation:
Advanced Installation
With the changes to Unity Package Manager in 2021, experimental packages will not show up in the package list and have to be installed manually. There are two recommended ways to install the package manually:
...
Once you've done that you can use pre-release:
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
My team is developing a Visual Studio Code extension, and we're considering to release some of our new features as preview/beta only shown to a limited number of users.
We can think of ways to do it manually, but were wondering if Visual Studio Code provides any "standard" way to release such preview features, in a similar way as what is done for Visual Studio Code Insiders.
Is there a standard way to release preview features in VS Code extensions?
In vscode 1.63 an enhanced ability to preview pre-release extensions has been added, see release notes: pre-release extensions.
As VS Code now allows extensions to offer pre-releases, you can opt-in
to install them and use the latest cutting edge features from
extensions. VS Code shows an additional Install Pre-Release Version
option in the extension Install drop-down menu for installing the
pre-release version of the extension.
Once installed, the following indicators make it clear if you are
using the pre-release version of an extension:
If there is a pre-release version of an extension that you have
already installed you can easily switch to it:
To publish a pre-release version, see release notes: publish pre-release extension versions.
Publishing Pre-Release Extensions
VS Code now supports extension authors to publish pre-releases for
their extensions through vsce by passing --pre-release flag. You can
now make your latest features available to users who chose to install
pre-releases and get early feedback before the official extension
release.
vsce publish --pre-release
VS Code Marketplace only support major.minor.patch for extension
versions and semver pre-release tags are not supported. Support for
this will arrive in the future. Because of this we recommend that
extensions use major.EVEN_NUMBER.patch for release versions and
major.ODD_NUMBER.patch for pre-release versions. For example:
0.2.* for release and 0.3.* for pre-release. VS Code will auto
update extensions to the highest version available, so even if a user
opted into a pre-release version and there is an extension release
with a higher version, that user will be updated to the released
version.
More information about pre-release extensions can be found in the Pre-Release Extensions topic.
No, I don't think there's a standard way of doing this, which leads to different extensions taking different approaches:
The C# extension requires you to uninstall the marketplace / release version. Then you need to manually download the .vsix file for the beta release from GitHub and install the extension from that. It looks like the Go extension is taking the same approach.
Other extensions have two different versions published in the marketplace, such as PowerShell and PowerShell Preview. The latter has a preview badge in the marketplace by specifying "preview": true in package.json:
This approach also requires manually uninstalling or disabling the original extension before you can use the preview version.
Finally, some extensions include experimental features in regular marketplace releases, but lock them behind a setting so users can opt-in. There's some risk of breaking non-experimental functionality this way if things aren't tested well.
There's also an open feature request with a pretty lengthy discussion on this topic, so there might be an official solution someday:
Allow extensions to publish beta releases and users to opt-in to them (#15756)
Vignette upgrades are usually not straightforward. You basically have to do a new installation and migrate over all of your customizations etc. Does anyone know if the upcoming V8 version is easier to upgrade or if its easier to upgrade from a certain previous version compared to earlier version. So I can upgrade to an earlier version (say 7.6) and then hopefully its easier?
Vignette v8 is officially not out yet, its only been soft released to some selected clients. My guess is that the upgrade will not be very straightforward but I've no concrete information on that.
During the wait you might also be interested in an open source alternative of Vignette v8 freely available: Sense/Net 6.0 http://blog.sensenet.hu/post/2009/08/05/An-Open-Source-Alternative-for-Vignette-v8.aspx
I have finally found the answer. You do need to upgrade to 7.6 before upgrading to 8.0 from an earlier version.