-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using the Jabref 5.0 release then going back to 4.3.x will break the UI because of shared settings #6234
Comments
Thanks for your suggestion, However, I think it's unlikely we will change that as JabRef 5.0 is a new major release. While JabRef is backwards compatible (it can migrate settings and fields from previous versions, it's not forward compatible. With a different storage of preferences this would make no sense. However, what indeed is necessary is that the portable version should not mess with the registry settings. |
@Siedlerchr : Are you sure you don't want to tackle this? Changing the registry path for the settings of JabRef 5.x versions would be a minimal effort and allow for both versions being worked with next to each other. IMO it is common best practice to prevent a registry conflict with newer software versions by using new paths (or field names) if necessary. It would also allow developers and users to quickly try out new betas/alphas without messing up the settings. |
@Sethur Could you please provide me some information why you are going to use 4.3.1 and 5.0 in parallel? We are working hard on improving the latest development version. We have limited resources and want to foster the expericence of the latest version. Could you please try the latest develoment snapshot: https://builds.jabref.org/master/? We tackeled performance issues (Refs #4430) Maintaining two preferences is not just about two nodes in the registry - as we offer migration etc. Have to think longer about converting etc etc etc |
@koppor : We are currenlty using JabRef as a group for a larger publication database (>2500 entries). It is important that everything works smoothly, so I want to avoid installing new major releases unless the new features are worth the risk of instability / breaking of the database. We have been using JabRef 3.x for a long time, but since I needed the feature to guess the meta info of PDFs based on content, we updates to 4.x at some point, after I had evaluated that the performance and stability had reached a satisfactory degree. For this evaluation, I had to use both versions in parallel, as I was doing now with JabRef 4.x and 5.x. Frankly, I have never come across any software where things break so bad when you run a newer version and then go back to an older one, while only working on isolated input data made for the particular version. I can understand that developers at times have to drop backwards compatibility (e.g. for the database, as happened at the jump of 3.x to 4.x) because of limited resources, but using identical setting files/registry folders and not taking care of compatibility there is - in my opinion - very unexpected behavior for any kind of software and should be avoided whenever possible. You said that just using separate folders is not possible because you are migrating the settings. Without knowing your code in detail I would still argue that you can still easily migrate the settings from the old 4.x registry folder to the new 5.x one by using almost the same logic, you would just need to clone the old settings to the new registry folder first and then do everything as before in the new folder. |
I missed this one, and it sort of answers your own question: I have and cannot easily try any other dev-versions of JabRef 5.x precisely because it will mess up my settings for our production version of JebRef 4.x. I would need to do that on another machine or in a VM, which would be a hassle to setup just to quickly check a new snapshot for performance/stability. |
I understand that you have preferences which you cannot loose. Double check: The preferences are something configured there: Note that JabRef stores the most important settings in the library ( Now comes the workaround proposal Have JabRef 5.x portable edition in use.
This way, you can avoid the VM. Meanwhile, I'm thinking of providing a patched version of JabRef 4.3.1. - Regarding of our increasing amount if issues (https://github.com/JabRef/jabref/projects/5) (not features), and the decision that we want to have the latest JabRef version always being the best version, it is hard for me to work a concept for 5.0 with different preferences. This refs JabRef/user-documentation#227 and #5730. |
@koppor : Thanks for the workaround, this will work, as will exporting the folder in the windows registry directly and then just importing it after going back to 4.x. However, both are a hassle and new users will not expect something like this to happen. Instead, they will probably thing (like me) that they just killed their database. I understand that you have a lot of issues to tackle with 5.x, but IMO, this is one of them, and it should be quite high up the list. Since I did not understand what part of changing the path in the registry for JabRef 5.x would be so difficult, I actually looked it up in the source code now, and since you are using the Java Preferences API, it should be as easy as changing the variable Edit: And yes, there needs to be some more work regarding the proper selection of preferences nodes for the migration of old settings when coming from previous versions, but that's it. I think this would be well worth the effort. |
@Sethur Thank you for looking into the code. Maybe you find some time to support our development. Bug fighting, a new feature. Whatever you feel comfortable --- The good newws is: We finally worked on a fix at #6296. Should be in master soon. If you want, you can test the binaries https://builds.jabref.org/pull/6296/merge/. |
@koppor Thanks for pressing this fix. I see that you chose to change the conflicting variable names for 5.x rather than using an entirely new node name (which would translate to a new registry "folder" with Windows). Not sure why you wanted to go trough the hassle of changing all the variables, but I'm happy as long as there are now more conflicts. I'll certainly come up with some more bugs / pull requests if I find the time. EDIT: BTW: While downloading the test build I realized that there are now bundles without the Java JRE any longer. Is this intentional? 340 MB is a lot of data for an app like JabRef. Compare this to the 4.x and 3.x releases with around 55 and 34 MBs. |
@koppor : Ok, I found out why the releases are so large. Not only do you bundle the Java JRE now, but there are also jfxwebkit dynamic libraries for both windows and linux/mac inside the JAR-file even not matter what bundle you chose. Besides that, there are also tons of redundant dlls (api-ms-win-...) in the main JabRef jar file, which are already present on the lowest level, but the double WebKit is definitely the main culprit. |
@Siedlerchr : Well, the full JDK for Java 11 to 14 is around 300 MB when installed, while the JabRef runtime directory for 5.x is >210 MBs, so I would guess that something went wrong with jpackage/jlink. I put in an improvement request for this here: #6340 |
bef74ed Create conservation-science-and-practice.csl (#6258) 9fb7eb7 Bug fixes triangle.csl (#6251) e6112ba Update ucl-university-college-apa.csl (#6250) 6dcba3a Update engineering-technology-and-applied-science-research.csl (#6247) 00fe4a2 Create constructivist-foundations.csl (#6243) 03ad71b Create les-mondes-du-travail.csl (#6234) a2bce86 Corrections based on author instructions (#6306) git-subtree-dir: buildres/csl/csl-styles git-subtree-split: bef74ed
f6c778e Update emerald-harvard.csl (#6335) d6c6a16 Fix Brazilian quotes on chicago-author-date.csl (#6317) a1549b6 Update medizinische-hochschule-hannover.csl (#6330) da88073 Update journal-of-the-american-college-of-cardiology.csl (#6334) a520d8e Bump nokogiri from 1.13.9 to 1.13.10 (#6333) ba54b44 Update royal-society-of-chemistry.csl (#6328) 1378ba7 LUSEM: Remove full stop (#6332) 9e3cf89 Create interpreting.csl (#6254) bef74ed Create conservation-science-and-practice.csl (#6258) 9fb7eb7 Bug fixes triangle.csl (#6251) e6112ba Update ucl-university-college-apa.csl (#6250) 6dcba3a Update engineering-technology-and-applied-science-research.csl (#6247) 00fe4a2 Create constructivist-foundations.csl (#6243) 03ad71b Create les-mondes-du-travail.csl (#6234) a2bce86 Corrections based on author instructions (#6306) git-subtree-dir: buildres/csl/csl-styles git-subtree-split: f6c778e
84dba23 Update international-union-of-crystallography.csl (#6279) 13dd9e8 Update zeitschrift-fur-deutsche-philologie.csl (#6340) d95b652 Create cahiers-mondes-anciens.csl (#6203) ded567c Create rassegna-degli-archivi-di-stato-bibliografia-generale.csl (#6275) 124777a Create scientific-online-letters-on-the-atmosphere.csl (#6261) 3c276e7 Create american-medical-association-no-url-alphabetical.csl (#6252) 595ad95 Bump mathieudutour/github-tag-action from 6.0 to 6.1 (#6287) 7008128 Create cambridge-a (#6336) 17e930c Update norsk-apa-manual-note.csl (#6338) b360859 Update norsk-apa-manual.csl (#6337) f6c778e Update emerald-harvard.csl (#6335) d6c6a16 Fix Brazilian quotes on chicago-author-date.csl (#6317) a1549b6 Update medizinische-hochschule-hannover.csl (#6330) da88073 Update journal-of-the-american-college-of-cardiology.csl (#6334) a520d8e Bump nokogiri from 1.13.9 to 1.13.10 (#6333) ba54b44 Update royal-society-of-chemistry.csl (#6328) 1378ba7 LUSEM: Remove full stop (#6332) 9e3cf89 Create interpreting.csl (#6254) bef74ed Create conservation-science-and-practice.csl (#6258) 9fb7eb7 Bug fixes triangle.csl (#6251) e6112ba Update ucl-university-college-apa.csl (#6250) 6dcba3a Update engineering-technology-and-applied-science-research.csl (#6247) 00fe4a2 Create constructivist-foundations.csl (#6243) 03ad71b Create les-mondes-du-travail.csl (#6234) a2bce86 Corrections based on author instructions (#6306) git-subtree-dir: buildres/csl/csl-styles git-subtree-split: 84dba23
JabRef version 5.0 and 4.3.1, Windows 10, Bundled JDK 13 and Java 1.8.0_241
I tried the current JabRef 5.0 release today on our database with approx. 2000 entries. Since I was not satisfied with the overall performance (startup time, notable lag while typing, scrolling, etc.) and resource uptake (both CPU and memory) I wanted to go back to Jabref 4.3.1. Note that I did NOT save the BIB-file in Jabref 5.0.
Unfortunately, after going back to 4.3.1., the settings of the table view seemed to have been completely messed up. Most of the columns had different names and where empty. At first I thought the BIB-file was changed, but I did a diff on a recent backup and that was not the case. It turned out, that the preferences that are saved in the windows registry for Jabref 5.0 are incompatible with the settings for previous versions but are still saved at the exact same location. This then brakes the UI.
My suggestion would be to change the path in the registry where JabRef 5.x stores its settings in order to prevent this behavior.
The text was updated successfully, but these errors were encountered: