Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Please update JabRef #6

Closed
koppor opened this issue Jul 27, 2016 · 30 comments
Closed

Please update JabRef #6

koppor opened this issue Jul 27, 2016 · 30 comments

Comments

@koppor
Copy link
Contributor

koppor commented Jul 27, 2016

JabRef released a newer version and it seems that @Vaquero84 (or @thigg?) just has to regenerate chocolateyInstall.ps1.
@OlafHaag
Copy link
Owner

New versions are commited to the chocolatey package feed. Waiting for approval.

@koppor
Copy link
Contributor Author

koppor commented Sep 7, 2016

JabRef 3.6 is available on chocolatey since August, 29 and awaiting moderation. Thank you for the quick update!

@koppor koppor closed this as completed Sep 7, 2016
@OlafHaag
Copy link
Owner

OlafHaag commented Sep 7, 2016

The problem lies with the jre dependency and the recent chocolatey update to not allow for empty checksums. The JRE package wasn't yet updated to include checksums, so the installation of the jabref package on their validation system fails as well. The admins had been informed immediately and told me they are working on it with the maintainer, but nothing happened so far...

@tobiasdiez tobiasdiez mentioned this issue Sep 26, 2016
Closed
6 tasks
@koppor
Copy link
Contributor Author

koppor commented Nov 14, 2016

JabRef 3.7 was released. Is it OK to ask here for an update? 😇

@OlafHaag
Copy link
Owner

I'll try to update the package as soon as an issue with chocopackageupdater is resolved, which unfortunately doesn't work on my freshly setup system.

Am 14.11.2016 um 14:47 schrieb Oliver Kopp:

JabRef 3.7 was released. Is it OK to ask here for an update? 😇

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEaohTrRSdBE3LFXFVaE3kA9-kougpT3ks5q-GZbgaJpZM4JWHZq.

@koppor
Copy link
Contributor Author

koppor commented Dec 16, 2016

We released JabRef 3.8 today. Maybe this could convince the issue to go away :)

@OlafHaag
Copy link
Owner

OlafHaag commented Dec 16, 2016 via email

@koppor
Copy link
Contributor Author

koppor commented Jan 30, 2017

Yeah, chocolatey package 3.8.1 was approved yesterday 🎉. We also released JabRef 3.8.2 yesterday. Is it possible to update it? 🤞

@OlafHaag
Copy link
Owner

My setup now looks every day for an update again.

@koppor koppor mentioned this issue Jun 5, 2019
Closed
@koppor
Copy link
Contributor Author

koppor commented Mar 17, 2020

The automatic update seems to fail for JabRef 5.0 (https://github.com/JabRef/jabref/releases/download/v5.0/JabRef-5.0.msi for Windows). Could you have a look please?

@OlafHaag OlafHaag reopened this Mar 22, 2020
@OlafHaag
Copy link
Owner

Thanks for the report and sorry for the delay in response.
Actually, I thought @tobiasdiez was working on taking over maintainership for the chocolatey packages by incorporating them into the build process.

But I see, my AU script is failing with jabref for a while now.
I'll have a look. I also see there's a portable version, so I'll take the opportunity to create a package for it as well.

@OlafHaag
Copy link
Owner

At this point I could maybe even add the development snapshots as a stream. But this would require that the version number changes for each snapshot, since I only compare those to determine if there's a new version available.

@tobiasdiez
Copy link

My PR JabRef/jabref#5378 concerns only the development version. I think it is easier to include the dev-stream as part of our deployment scripts (because it has access to the code to determine the exact version etc.).

If you want we can also include the chocolatey packages for the stable releases in the JabRef repository. But as you did a awesome job maintaining them so far there is no real need for action!

@koppor
Copy link
Contributor Author

koppor commented Mar 23, 2020

He started working on it at JabRef/jabref#5378. In our last JabRef devcall (https://github.com/JabRef/jabref/wiki/Minutes#2020-03-17-8oo --> SnapCraft dev build), we decided to

I volunteered to drive this as it seems "only" to be an issue with our GitHub actions (especially embedding https://github.com/marketplace/actions/chocolatey-action). I was just starting to understand what's going on and how the whole thing works.

@OlafHaag I would be happy if you kept maintaining the JabRef Chocolatey package - then the development team could focus on improving JabRef itself. 🎉

@OlafHaag
Copy link
Owner

Thanks for the update! Last night I went ahead and created new packages. Since I changed the setup to so-called virtual packages, I introduced 2 new packages (jabref.install & jabref.portable) which yet have to be approved by a chocolatey admin.

I also added a stream for the development snapshots, but that didn't quite work out the way I was expecting, because chocolatey only pushes the first updated stream and I couldn't manually push, because the stable packages weren't approved. So I'm glad you still have plans for that.

I'll let my script keep updating the stable releases.

If you want to have the descriptions changed for the packages, just let me know!

@koppor
Copy link
Contributor Author

koppor commented Mar 29, 2020

Thanks for the update! Last night I went ahead and created new packages. Since I changed the setup to so-called virtual packages, I introduced 2 new packages (jabref.install & jabref.portable) which yet have to be approved by a chocolatey admin.

Seems they are approved:

I also added a stream for the development snapshots, but that didn't quite work out the way I was expecting, because chocolatey only pushes the first updated stream and I couldn't manually push, because the stable packages weren't approved. So I'm glad you still have plans for that.

OK, I will work on it and hopefully succeed. Currently, https://chocolatey.org/packages/JabRef shows "JabRef 5.1-dev". Can you change that back to "JabRef"?

I'll let my script keep updating the stable releases.

Thank you!

@OlafHaag
Copy link
Owner

Unfortunately they are not approved yet. They both have the READY status, so some moderator can appove them. They only passed the automatic validation and verification.
This manual process of approval seems quite slow, I assume it's due to a huge number of packages and a limited number of moderators.
There's also a textbox saying

This version is in moderation and has not yet been approved.

The jabref package is a trusted package, meaning it bypasses manual approval (they must think I know what I'm doing). Since I changed it to a meta-package which only installs the jabref.install dependency that somehow works, even though the dependency isn't yet approved. From a security standpoint this should probably not be possible.

The website of the package only shows the latest version as a title, even if it's a pre-release, If you search for the package instead, it shows the latest stable version.

When I updated the dev-stream, the jabref 5,1-dev package went through, because it is trusted and a pre-release, but the jabref.install 5,1-dev and jabref.portable 5,1-dev packages were rejected and couldn't be pushed, because there's no approved version of them yet.

I can't change the package version once it's pushed. I can only push the same version as long as it is not approved, reject the package, unlist it, or push another version.

So now I wait. I could then try to push the 2 dev packages again or unlist/reject the 5.1-dev package and not push the missing packages until you have your setup ready.
What will the naming of the dev version be like? In the choco docs there's something about how it sorts them and determines which version is the most recent.

@koppor
Copy link
Contributor Author

koppor commented Apr 2, 2020

Thank you for the long explanation!

What will the naming of the dev version be like?

I will go for `jabref-nightly. (Similar to vlc --> https://chocolatey.org/packages/vlc-nightly).

@OlafHaag
Copy link
Owner

OlafHaag commented Apr 2, 2020

I will go for `jabref-nightly. (Similar to vlc --> https://chocolatey.org/packages/vlc-nightly).

Aha, so you want to create a new package instead of pushing to the already existing packages?
I remember reading somewhere in the choco docs that it was encouraged to publich pre-release versions to the same package, only mark the version as pre-release, e.g. jabref 5.1.0.20200402-nightly, which in this case would only have a dependency on jabref.install 5.1.0.20200402-nightly.

But then, I guess, you can't choco install them side-by-side to still have the stable release around. Except for when one is the portable version...

@koppor
Copy link
Contributor Author

koppor commented Apr 2, 2020

@OlafHaag It seems, I understood something wrong. 😇 - Very good idea to have a pre-release version of the same package. Not sure what you mean by

At this point I could maybe even add the development snapshots as a stream. But this would require that the version number changes for each snapshot, since I only compare those to determine if there's a new version available.

(#6 (comment))

JabRef shows the updated version number in the about dialog (somewhere hidden since our switch to jpackage)

grafik

In our builds server (https://builds.jabref.org/master/), the time stamp changes, the filename does not. - Would it be possible to "just" create a new development snapshot each night? Maybe, it would be possibel to check for the timestamp on the server? Not sure? Maybe similar to wget -nc?

grafik

@OlafHaag
Copy link
Owner

OlafHaag commented Apr 2, 2020

If I make the date in the download links become part of the chocolatey package version for the nightly builds, then it should work.

If choco now allows SemVer2.0.0 then it could be 5.1-dev.20200331, but the status of chocolatey/choco#1610 suggests otherwise. So it would have to be 5.1.0.20200331-dev, for example.
Chocolatey allows for 4 version segments and the fourth is reserved for fix-notation, which may be suitable for jabref nightly builds, since the old nightly builds don't seem to be available for download anymore, hence breaking those packages.

The only problem rigt now is that those packages are still not approved and as long as that's the case, I can't push new package versions. I'll contact some admin about that.

@koppor
Copy link
Contributor Author

koppor commented Apr 3, 2020 •
edited
Loading

For pull requests, we create following SemVer:

"FullSemVer":"5.1.0-PullRequest6232.201",

(Using GitVersion)

For the master branch we produce:

"FullSemVer":"5.1.0-ci.193",

The number 193 is distance in number of commits from the latest release. This should be OK, shouldn't it?

@OlafHaag
Copy link
Owner

OlafHaag commented Apr 3, 2020

This should be OK, if choco supports SemVer2.0.0. Otherwise the 193 must be moved to the fourth version segment.

@koppor koppor mentioned this issue Apr 6, 2020
Closed
5 tasks
@koppor
Copy link
Contributor Author

koppor commented Apr 6, 2020

We discussed again internally. What I understood: Chocolatey offers full releases and pre-releses. No third mode. Since JabRef offers full releases and beta releases (e.g., 5.0-beta), we would like to have the alpha and beta releases published as pre-release.

I would then focus again on JabRef/jabref#5378 to offer jabref-nightly. Beging fully aware that parallel setup won't work (besides the user chooses the portable version for the one and the installed version for the other package).

Does that make sence?

@OlafHaag
Copy link
Owner

I think that makes sense. Users installing pre-releases are willingly taking the risk of using possibly unstable software. Even though a beta is probably more ready than a nightly build.

@OlafHaag
Copy link
Owner

At least the jabref.install package is approved now, so once you become a maintainer of the packages on chocolatey.org you should be able to push the nightly builds. The jabref.portable package is still awaiting approval. The admins told me the majority of reviewers do that in their spare time so it can take quite some time.

@koppor
Copy link
Contributor Author

koppor commented Jan 12, 2021

I think, the decision is that we are very happy that you @OlafHaag continues with updating the packages. With the dev versions, we had issues (because of deploying nightly builds). We currently don't have time to work on that (therefore, we closed JabRef/jabref#5378).

As the most recent version of JabRef is available, I am closing this issue.

@koppor
Copy link
Contributor Author

koppor commented May 1, 2023

(CC of a message to chocolatey package community)

We (the JabRef team) noticed that the latest version is JabRef 5.8 and that there is a version 6.0 dev and version 5.9 is missing. 6.0 is no longer existing/not yet. We (the JabRef Team) originally planned 6.0 after 5.8 but needed to do a release meanwhile which is now 5.9
The latest dev version is now 5.10.

Addition:

Sorry for the inconvenience! We switched to 6.0-dev shortly after the release of 5.8, but decided to do 5.9-dev (which will be sort of maintenance release).

@Siedlerchr
Copy link

Hi, we just released Version 5.11 an the website still lists 6.0 pre release
https://community.chocolatey.org/packages/JabRef#versionhistory

@OlafHaag OlafHaag reopened this Nov 19, 2023
@OlafHaag
Copy link
Owner

Sorry it took so long for me to take a look. I don't actively use choco much anymore.
I used web-scraping before to find latest releases, so each time github would change their release page, it could break. I now switched to the Github REST API for the jabref repo's latest release which should be much more robust.

I also downgraded the dev-version, since it wasn't accepting "older" versions than 6.0.
New release packages are awaiting automatic validation/moderation.

@OlafHaag OlafHaag mentioned this issue Nov 19, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Siedlerchr @koppor @OlafHaag @tobiasdiez