My project has a bug. It currently uses v18.0.3. When I asked a question in another thread someone mentioned that I should better upgrade to v21, since that's an LTS version. I also recall having received news letters stating that v21 is supposed to be an LTS version.
If I looked at the Vaadin Roadmap (https://vaadin.com/roadmap) today there is no word that v21 is an LTS-version.
Rather v14 is mentioned as last LTS and v23 is apparently to become the next LTS version.
Have plans changed?
The most recent versions can be found here https://vaadin.com/releases
you'll see that 14 is the current LTS
You should definitely update from 18 to 21 even if 21 isn't an LTS version, because 18 is no longer supported. It'll also potentially make your update easier when the next LTS, 23, is released. With non-LTS versions, you should always update to the latest major to stay on a maintained version.
Related
Most of our systems are on Azul Systems JRE 11.0.6, which is causing a tremendous amount of vulnerabilities.
The recommended solution on fixing these issues is to upgrade to version 18 (latest version).
Is there any particular reason why a legacy version is still being used and not being upgraded? (ie dependancies)
Any follow up would be greatly appreciated.
Thank you!
I'm using Grails 5.1.4 for a number of projects now, and planning to move to 5.1.7 soon. I've been continuing to develop with Java 8 and deploy with Java 11, but I'm wondering whether there is a more recent version which I could be using without problems? The docs talk about the minimum JDK version required (8), but not the maximum usable one.
Are there any special reasons why Cygwin Clang is so outdated (see here), version 8, while already version 13 exists?
For example Ubuntu (apt), MSYS2, MSVC all have version 12.
Also does anyone know (any links?) if there is any very simple way (like docker-based) to build recent Clang for Cygwin? Maybe Clang has no support for Cygwin anymore, that's why Cygwin has outdated version?
See:
https://cygwin.com/packages/summary/clang.html
The reason is very simple, there is no current maintainer.
The previous one has no more available time to dedicate to the project.
I have recently upgraded Neo4j from version 3.5 to version 4. The question is, in order to update Neo4j to the latest maintenance release, is it necessary to do all steps outlined in this link https://neo4j.com/docs/operations-manual/current/upgrade/, or it will be correct and sufficient to download the latest version and copy the data directory to the new Neo4j installation ?
The steps documented in the link has been done when moved from 3.5 to 4.0.3. I am going to update it from version 4.0.3 to version 4.0.4.
There is also a nice video from David Allen about the upgrade process
https://www.youtube.com/watch?v=GcaJ-aVLzr4
For certain reasons (Oracle, I'm looking at you) I need to be able to use 32 and 64 bit versions of ruby. Can I have both 32 & 64 bit versions of 1.9.3 installed side by side with rbenv? How would I be able to tell them apart when I run rbenv versions?
Right now I'm using a 32 bit version of 1.9.2 and a 64 bit version of 1.9.3. I would much prefer to have a 64 & 32 bit version 1.9.3.
UPDATE:
For now I've just chosen to use a different patch. There has to be a better way...
UPDATE 2:
To clarify my situation, I'm using a machine that runs on Mac OSX Lion.
this link describes my main problem, no 64bit instant client for Lion
This link shows the only solution I've found to the problem
UPDATE 3:
This is no longer an issue, because oracle released a 64 bit instant client that works on Lion and Mountian Lion.
You can have as many arbitrary builds of Ruby installed in rbenv. It doesn't care as long you give them each a uniquely named directory/symlink in ${RBENV_ROOT}/versions/.
By default, it seems that Rubies built on OS X are 64bit. If you can figure out how to configure 32bit build of Ruby, you could install one with PREFIX="$(rbenv root)/versions/1.9.3-p194-32", for example. Then you can use that version as any other:
RBENV_VERSION=1.9.3-p194-32 ruby -v
Here I used "-32" prefix to tell versions apart.