Hey, i was wondering if we could add some information about the development version in the forum, roughly similar to how syncthing is doing it. See here:
This would be for all the folks that come to the forum with a question and the answer is to install the development version, because in the development version it already was fixed.
It also would be nice to have a rough estimate of when to expect a new major stable release, although i can understand if we want to remain very flexible there. Last time when 5.5 was published, i really was surprised, because i did not see it coming. I was not doing any tests on the latest development version prior to the release, if i remember correctly, because i did not think it would be pushed to stable. Maybe one week of testing before publishing it would be something worth considering?
For anybody who is interested in syncthing’s candidate release model, merge timing and surrounding issues, see here and here. Not saying that such a model also does not have its issues.
Long story short, if it were decided to publish the timing of the next stable release (maybe one or a few weeks prior), my proposition is for it to be mentioned at the top of the forum, just like syncthing is doing it.
On the one hand, we see the need to have a version being testable. On the other hand, it is difficult to maintain a multiple branches. Those branches could be: stable, beta, testing.
6 years ago, we found the situtation that there were beta releases, which were updated constantly before a release. Thus, there was no feature freeze and the beta version were somehow “random” versions.
The current situation is as follows: We integrate all reviewed bug fixes and features in the main branch and have users testing these releases. Roughly, each three days, a new build is available at https://builds.jabref.org/main/.
You can see the next planned releases at Milestones - JabRef/jabref · GitHub. As of today, we plan two: One bug fix release (being 5.6) and a new full release, being 6.0. When the number of issues go down, we release.
What we can do, is that we write a “News” if we plan to craft a new release the next weeks. Typically, we know that after a developer’s call (see our Minutes at Minutes · JabRef/jabref Wiki · GitHub).
Side note: JabRef is backed by JabRef e.V., which is a non-profit organization (where every user is invited to become a member of; write me a personal message for details). Currently, all developers are working on JabRef in their free time and are refunded for their efforts. We hope for increasing donations (see https://donations.jabref.org/ for details) and that they will fund a student for working supporting other code contributors, working on fixes and new features. Still, this will not be enough to change our release model.
Note that syncthing is backed by a company - which also funds developers.
Also, i agree, there does not need to be a change in release model. All i am proposing is:
A link to the latest “stable” Jabref version and also a link to the latest “development version” aka main branch at the top of the forum. It looks really fancy how Syncthing did it.
a warning/news that a release will be done soon, so that people can knot some loose, but trivial, ends. Stuff that does not completely break Jabref, but small little things that probably should be in a stable release and also so that people that test the version actually do have time to test the newest main branch. I am not asking for a beta release, no worries
To make this clear: Right now it is very hard for users to accurately find out when a new release will take place.
dev call minutes are not very helpfull in this regard:
5.4 was released on the same day as the dev call:
5.5 release was not even mentioned in dev call minutes
Milestones and labels like “blocks X.y release” would are awesome, but unfortunately not a lot of Jabref developers and maintainers use them. Currently, you Oliver are the only one that has any assigned issues in “5.6 release” milestone.
In general, milestones would be a good rough indicator for when the next release will happen. The intuitive assumption would be like this: When there is no issue attached to the next milestone, then a release will happen very soon (unless a release just happened and the process of attaching issues to the new milestone has yet to happen).
It is just that … some issues have been attached to milestones, while having never been successfully solved and are not actively being worked on right now. Releases are done, even though a fix to this issue was supposed to be in the release. An example would be Fix exception when saving and autosave trigger at the same time]
On a side note: I love the JabRef projects page on github, and it is really useful to get an overview about existing bugs and relevant issues and the like and it gives an idea when something will be worked on, but when it comes to releases, it does not seem to help finding out when the next release will be, because jabref maintainer’s focus is sometimes out of date and not used by everybody and there is no area for releases (which is fine! I am not advocating to put a release area into the projects page. It is fine as it is!).
Maybe i am just overly sensitive here, because it is completely natural that documentation, categorizing and sorting comes after people actually do the important stuff…
Some kind of news still would be the best, because as long as milestones are not actively maintained, they cannot be accurate, and even if they were maintained properly, then one never knows if an empty milestone denots a release will be there soon, or if somebody suddenly will put another issue unto the milestone…
5.5. was a bit of a special case, it was more like a 5.4.1 an immediate bugfix release.
We normally also prepare a blog post in advance.
We otherwise have no fixed release schedule, as this depends a lot on time and other available resources and depending on how “big” (fixed bugs, features) the release already is.
But in general I think we can agree on announcing a new release in advance. We also use this period for the translators to translate the latest changes on Crowdin.
this would be nice!