app-text/jabref versions prior 4.x were very stable and could be used for the everyday work. Since upstream rewrote the code it is hardly usable any more. Other users report severe bugs including freezing and broken databases. I can confirm this too, the upstream bug tracker speaks the same language. In the 4.0 release a simple doi import and dragging it to a category crashes Jabref. The user can not step back to 3.x, if Jabref 4.x loaded and converted the .bib database once. I think we should protect the user by masking this package with an appropriate warning.
Thanks Jonas for the information! I am using version 4 but haven't run into issues so far. I'll mask the package though until upstream figures things out.
Mask is in tree.
Thank you. I reopen to add some ideas for a longterm strategy. I have discussed the release strategy with upstream. https://github.com/JabRef/jabref/issues/3380 The next releases 4.x will be just one of many development releases. https://builds.jabref.org/master/JabRef-4.1-dev--snapshot--2017-11-01--master--84e90719a.jar and https://builds.jabref.org/master/JabRef--master--latest.jar are the same. Its rebuilt a few times a day from the latest source. My suggestion: we mirror (where? has java devspace? personal devspace can not be used when bumping as other user, mirror:gentoo is not allowed for SRC_URI...) from time to time a copy of the latest 3 snapshots. wget https://builds.jabref.org/master/JabRef--master--latest.jar -O "jabref-4.0_p`date +%Y%m%d%H%M`.jar" which makes a jabref-4.0_p201711011320.jar we need the time, because there are several builds per day. Besides that should we provide a -9999 ebuild which pulls with wget in src_unpack
prepared a 4.9999 ebuild for the generation-4 development snapshots: https://github.com/jonasstein/jstein-overlay/tree/master/app-text/jabref-bin You may merge it to the tree, if you like.
The 9999 version has been added to the tree. Can we close this bug then?
Jonas, do you think we need snapshot packages in addition to the 9999 ebuild?
Yes, we should provide from time to time a frozen, working 4.x ebuild, because the 9999 ebuild relies on the upstream master. Upstream does not test carefully before merging and it can happen that the .jar is not really usable for several days. We should provide the users of 4.x a "fallback" version, which works somehow at least and can open the database. You could see this as alternative for the broken 4.0 release, which we should remove from the tree then.
jabred-4.1 was released some time ago. It is not that dangerous as 4.0, but still not usable for productivity. But I think it is worth to provide 4.1 in the tree as hard masked package for the brave users.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fcec3deb27c3c0768a61b4dc527402c28892afc5 commit fcec3deb27c3c0768a61b4dc527402c28892afc5 Author: Nicolas Bock <nicolasbock@gentoo.org> AuthorDate: 2018-01-10 16:22:49 +0000 Commit: Nicolas Bock <nicolasbock@gentoo.org> CommitDate: 2018-01-10 16:26:45 +0000 app-text/jabref-bin: Version bump to jabref-bin-4.1 Bug: https://bugs.gentoo.org/show_bug.cgi?id=636036 Package-Manager: Portage-2.3.13, Repoman-2.3.3 app-text/jabref-bin/Manifest | 1 + app-text/jabref-bin/jabref-bin-4.1.ebuild | 48 +++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+)}