I had new changes to my code. These changes use new Node 14 features, such as Optional Chaining. This has caused problems for clients running version 12 of Node.
Should this new version be major or not?
TL;DR: you almost certainly should have released that as a major version, yes.
As I see it, there are three possibilities, depending on the package's declared Node version support (usually included as $.engines.node in package.json):
You explicitly supported Node 12, and are now dropping that support.
This requires a major version change, your changes are not backwards-compatible. Steps to mitigate, assuming the current version is x.y.z:
Re-release the new version that uses incompatible syntax as (x+1).0.0;
Release a new version x.y.(z+1), reverting the changes to restore Node 12 compatibility, to get folks' builds passing again; and
Consider releasing x.(y+1).0, implementing the new functionality with backwards-compatible syntax (as Node 12 is still in LTS, see #3).
You explicitly didn't support Node 12.
This doesn't require a major version change. Nobody should have been using it with Node 12 to begin with and it's not really your fault they're now having problems.
That said, given that people apparently were using it with Node 12 (which is still in LTS, see #3), you may choose to support them by doing the steps in #1 anyway.
There was no/unclear explicit Node version support.
In the absence of an explicit support declaration, I would go back to Node's own support - Node 12 is still in LTS until the end of April 2022. Therefore I'd expect any actively maintained package that didn't specify otherwise to continue to support Node 12 usage too. You should therefore follow the mitigation steps in #1.
I would also consider being more explicit about what is required/supported, by adding the information mentioned above to the package file in all of the new releases (e.g. for the optional chaining in (x+1).0.0, per node.green, ">=14.0.0").
Finally I would note that you can use the latest syntax in your source code but still support older Node versions through transpilation, publishing code generated by e.g. Babel rather than the source code itself.
Related
I try to use this source https://github.com/JoseExposito/v8-compiler/blob/master/addon/v8-compiler.cpp in my project. But a function compilation_cache() called from runScript always returns NULL. What can be wrong? What I need to fix in the source to work with the later version of v8?
In addition, why is there no flag in the latest version of v8 FLAG_serialize_toplevel?
Two parts here:
First a warning: you should definitely not be writing code using any part of the i (internal) namespace. The APIs in the internal namespace don't always reflect how JS actually runs (due to optimizations), plus they change often and without warning.
In the case of the code you copied from V8 internals, V8 already provides an API to produce and consume "cached data" which is just the bytecode in a serialized form. Here's an example from the source of Node.js for how to produce a code cache.
Secondly your actual question: V8 will always perform a check on bytecode using a special hash (basically V8 version and source text length) and if it doesn't match it won't use the bytecode cache. This is why changing V8 versions causes the bytecode to be rejected.
I wanted to download Linux kernel 2.6.38 source files from https://www.kernel.org/pub/linux/kernel/v2.6/
but the webpage listed linux-2.6.38.1.tar.xz, linux-2.6.38.2.tar.xz etc, as well as linux-2.6.38.tar.xz.
What's the relationship between them? Which file should I choose?
These number represents the kernel version/releases, and give us information about its stability. From here :
The first number denotes the kernel version. It is changed least
frequently, and only when truly major changes in the concept and the
code of the kernel occur. In fact, it has been changed only twice in
the history of the kernel: in 1994 with version 1.0 and in 1996 with
version 2.0.
The second number denotes the major revision of the kernel version. It
was formerly the case that even numbers indicated a stable release,
that is, one that was deemed fit for production use (i.e., use in a
non-experimental environment), such as 1.2, 2.4 or 2.6. Likewise, odd
numbers, such as 1.1 or 2.5, have historically represented development
releases. They were for testing new features and device drivers until
they became sufficiently stable to be included in a stable release.
However, this has changed starting with the Linux 2.6.x series, and
new feature development now takes place in the same revision number.
The third number indicates the minor revision of the kernel. It is
only changed when new features or new drivers are added.
The fourth number represents corrections, such as security patches and
bug (i.e., error) fixes.
I work with Perforce streams, following the suggested mainline model (release, mainline and development streams). In addition, we use a odd/even release version numbering (similar to linux kernel) with odd minor version numbers for development versions, even minor numbers for release versions.
After fixing a bug in a release stream, I need to update several files with version information to create a new release version/installer. These version changes must not be merged to mainline (only the bugfix itself), because the version of the mainline has been already increased to the next development version.
Now, when merging from the release stream to main, I get conflicts for all files containing version information. Currently, I need to manually resolve all conflicts, undoing the version number change (keeping the development version).
Example:
Release stream started with version 2.4.0 (stable/release version number)
Increase mainline version to 2.5 (next development version)
Fix bug in release stream, increase version number to 2.4.1
Merge changes to mainline: accept bugfix, manually undo conflicts in version files
Is there a way to exclude single files / a set of files from integration so that I don't have to go through this tedious (and potentially error-prone) manual process? (NB: The version information is separate from the code.)
Three possible options:
1) Specify these files as "isolate" in the stream spec so that changes to them are isolated, i.e. not included in copy/merge operations.
2) Merge the version changes but use "resolve -ay" (ignore) to specify that these changes are to be ignored.
3) Revert these files after opening them for a merge operation so that you will not need to resolve or submit them.
When compiling different versions of the Linux kernel, every now and then I see some drivers being dropped in favor of others.
For instance, the commit 5772dcaa790851ec068afcd0d1f160d801b1126e drops (removes) the IBM driver for the Xirlink C-it Camera, located in drivers/media/video/usbvideo/ibmcam.c in the v2.6.37 branch. The newer driver appears in v2.6.38 at drivers/media/video/gspca/xirlink_cit.c.
For that particular driver, I see that all devices supported by the newer driver are supported by the old , as written in its usb_device_table, defined in xirlink_cit.c. However, I don't see any alias from the newer driver module towards the older. I know the existence of the MODULE_ALIAS macro, but in this case in particular, I don't see it being used.
That said, I want to know all possible ways in which aliases can be programatically defined.
Any help appreciated :)
ATL uses thunks to manage callbacks for windows, and apparently it needs to allow for data execution.
Microsoft says:
Note that system DEP policy can override, and having DEP AlwaysOn will disable ATL thunk emulation, regardless of the attribute.
Am I correct in translating this quote to (more or less) "ATL applications can crash due to system policies"?
Is there a way to make a pre-ATL-8.0 application work correctly on any system, hopefully while still turning on DEP for everything other than the thunk?
DEP is enabled per process, so you cannot disable DEP for the buggy fragment only. The options are either to rebuild a binary with fixed ATL to make the binary DEP-compatible, or disable DEP for the whole process where the binary is used.
Earlier ATL versions indeed had this problem and it was fixed at some point.
DEP exceptions are under My Computer, Advanced tab, Performance Settings, Data Execution Prevention.
It is not a problem with ATL 8.0:
If possible, replace the older components with ones built to support
the "No eXecute Compatibility", such as those using ATL 8.0 or newer.
The ATL thunk strategy was devised as a lookup convenience and to
avoid using thread-local storage for a window-handle-to-object map,
but the thunk emulation required in DEP-aware OS's negates and even
reverses any performance improvement. Newer versions of ATL don't
require the thunk emulation because their thunks are created in
executable data blocks.
EDIT: Sorry, didn't notice you asked about pre-8.0 ATL.