-
-
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
distribution of a more stable Jabref 4.x #3380
Comments
We are sorry, that the major version caused so many troubles. In the meantime we can only suggest to use the development version. However, they change often as soon as new PR gets merged. |
Will the 4.1 release be stabilized with some clever procedure, or is it a month after 4.1 better to use the development version again? On Gentoo, we can distribute technically also a 4.1_p20171103 version which is the 4.1 release with all patches from the development version by the date of 2017-11-03. So the question is just what is best for the user? |
This is just my personal opinion: I do not expect JabRef 4.1 to be 100% bug free by some clever procedure and after a month or so it will be better to use the development version again. This is not just, because the software is so full of bugs (there are many, as you know), but also because the surroundings constantly change, e.g. some web service makes changes to its API and we can no longer fetch DOI information or something similar. Overall, our policy is to release frequently, but now and then there are major problems that push release dates, as it has been the case with 4.0. In my opinion it would be best for the user if you distribute development versions now and then. But as I said, this is just my personal opinion and the other devs might disagree. |
Similar to @lenhard just a personal opinion, but coming from a user perspective: If it is not too much work, I would recommend to distribute both JabRef 3.8.2 and the current development version 4.1 with Gentoo (or other Linux distributions). This would be similar to the LibreOffice release cycle, which offers a stable and a 'fresh'/more experimental release. JabRef 3.8.2 would be the 'stable' one and the development version 4.1 the 'fresh' one. I'm personally still using JabRef 3.8.2 due to the mentioned issues, but I also have the developmental version 4.1 installed which I try to time from time to see, whether I can switch or not. This would only apply to this period of transition where some users might prefer the more stable 3.8.2 release while others need the new features of 4.0/4.1. Again, this is just coming from a user perspective - I have no idea, whether this is feasible or how much additional work this would create. |
@lenhard and @AEgit thank you for your opinion. We can provide many versions at once and let the user select. I think it is the best to ignore the releases 4.x then until they have some special meaning and provide often an updated development release next to the old frozen 3.x. Update for the interested reader: I have prepared a Gentoo package, which installs the latest development release. It depends on https://builds.jabref.org/master/JabRef--master--latest.jar, so please do not take it away ;-) |
The 4.0 release has major bugs. It freezes for example, if the user wants to drag an article in a group. (#3345) I tried to use it, but triggered a different bug every few minutes.
We already distributed 4.0 on Gentoo Linux and decided to move it from testing to our "danger zone", because of the instability. If a user is used to the 3.x versions and tries 4.x, the database is converted and he is left with a software which is much less stable than 3.x was.
Many bugs in 4.0 are already fixed in the latest development version. Is there any benefit in the 4.0 release over the snapshot release for the user?
How can we provide the best solution to our users? Should we distribute only the development releases on Gentoo, or will there be a new release 4.0.1, where the bugfixes are backported to 4.0?
The text was updated successfully, but these errors were encountered: