-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Releasing a new Version
- Ensure that all tests are green
- Execute test locally to ensure everything (especially the fetchers) is working
- Some fetchers may not work due to licensing. See https://devdocs.jabref.org/advanced-reading/fetchers how to get keys. More fetchers are enabled locally than on the CI, because of rate limits.
- Ensure that Snapcraft is running. For instance, at release 5.10, the underlying ubuntu image (20.04) was too old.
Hint: You can work on a branch
main-release
. This will trigger the GitVersion tool, but not indicate a real release. After JabRef works fine, you can push tomain
.
- Update Journal Abbreviation List and CSL styles
- These are managed by Dependabot. Trigger Dependabot manually under https://github.com/JabRef/jabref/network/updates for .gitmodules
-
Update
external-libraries.md
. Howto inside. -
CHANGELOG.md
- Change version from
[Unreleased]
to[5.2] – 2020-10-03
. - Remove empty sections of the release.
- At the very end of the file:
[5.2]: https://github.com/JabRef/jabref/compare/v5.1...v5.2
- Change version from
-
GitVersion.yml
:-
No changes required except if a) there was an alpha or beta release before or b) this release is an alpha or beta release
-
In both cases, the
tag
and thepre-release-weight
have to be changed according to:New release tag
pre-release-weight
alpha alpha
15000
beta beta
30000
stable ''
50000
Reason: we need to have an always increasing build number
-
-
snap/snapcraft.yml
. Check thatgrade
isstable
(should be)grade: stable
-
Create a release commit
-
git add CHANGELOG.md
(to stage the changes on CHANGELOG.md). Maybe usegit gui
. git commit -m "Release v5.1"
-
git tag v5.1
-
git push upstream v5.1
- to push the newly created tag -
git push upstream
- to push themain
branch -- an updated main branch is important for the build of the release to succeed (GitVersion). This update will use the tag pushed in the step before. - Wait until the build completes. DO NOT UPDATE THE
main
BRANCH. The important build is the build for thetag
. The parallel build onmain
is important for Snapcraft only.
- For GitHub-based builds, we notarize on the tag only
- Download binaries from the tag (This is important for mac because only the tag release gets correctly signed + notarized). https://builds.jabref.org/tags/. Additionally download https://builds.jabref.org/main/JabRef-$version-portable_linux.tar.gz to test the snapcraft build. One can start VMs using some of https://github.com/JabRef/jabref/tree/main/scripts/vms/.
- At least, quickly check if contents in Help - About JabRef are properly replaced. Also create a new library and create a new entry.
- Test https://builds.jabref.org/main/JabRef-$version-portable_linux.tar.gz -- this
.tar.gz
file is also used for the snapcraft release. - On macOS:
xcrun stapler validate JabRef-$version.dmg
pkgutil --check-signature JabRef-$version.pkg
-
FossHub (via developer account)
- It is very important to do that BEFORE GitHub, because of the auto update feature.
- Use tools/wget
- point to the binaries at the build artifacts of GitHub (the ones at https://builds.jabref.org/tag/v5.x also work)
- After the upload: adjust them under "files".
- (currently not working) Semi-automatic upload (see Tools - JSON on FossHub)
- adapt
upload-to-fosshub.json
- POST it to https://www.fosshub.com/JSTools/uploadJson
- adapt
- Manual upload:
- For each file:
- "Add File"
- Type: Select fitting type. E.g., "Windows Installer (32 bit)"
- Version:
v5.1
- Drag file
- For each file:
-
GitHub
-
Ensure that https://builds.jabref.org/tags/ contains a single tag directory only.
-
Do a release creation using the GitHub workflow Release binaries on GitHub running on the release tag. This automatically executes following steps:
- Create new release based on tag.
- Upload binaries to GitHub release page.
-
Turn the draft into a public release
- Add CHANGELOG.md text to the GitHub release
-
-
Snapcraft: Release to Ubuntu Store
- Ensure that the branch
main
was successfully build.snapcraft.yml
points to https://builds.jabref.org/main/, which needs to contain the released version. - Go to https://snapcraft.io/jabref/releases. Trigger a new build to ensure that the latest one of
main
is used. Then, release the build version tostable
and also tobeta
andcandidate
. Click on "Save"!
- The release version number should be ending in .60000. If not, there was a push to
main
meanwhile. - Other information is available at https://dashboard.snapcraft.io/dev/snaps/7999/
- One can use https://github.com/JabRef/jabref/tree/main/scripts/vms/ubuntu to fire up a VM.
- On Ubuntu
snap install --beta jabref
- Test whether JabRef shows the right version
- Ensure that the branch
-
- Not necessary anymore, because of https://github.com/vedantmgoyal9/vedantmgoyal9/blob/main/WinGetAutomation/Formula/j/jabref.jabref.json.
-
FlatPak.
- Check if https://github.com/flathub/org.jabref.jabref/ builds.
Ensure that snapcraft build was released. If you did not, you will get in big trouble. Main reason: Inside snapcraft.yaml
file, https://builds.jabref.org/main/ is used as source for the build.
-
CHANGELOG.md
-
At the beginning of the file:
## [Unreleased] ### Added ### Changed ### Fixed ### Removed
-
At the very end of the file:
[Unreleased]: https://github.com/JabRef/jabref/compare/v5.1...HEAD
-
-
Edit
snapcraft.yml
under/snap/
and change the download link to point to the new version cycle. See https://github.com/JabRef/jabref/pull/11467 for an example. -
Edit https://github.com/JabRef/jabref/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml and change to the new version
-
Update https://github.com/JabRef/jabref/blob/main/.github/workflows/gource.yml to use correct dates and filenames
-
gource_title
(2x),gource_start_date
(2x),mv
(at "Store video") (2x),gource_stop_date
(1x)
-
After a stable release, set
pre-release-weight
inGitVersion.yml
back to0
. -
Commit the changes for the new dev cycle
- git commit with message:\
Start new development cycle +semver: minor
- Without
semver: minor
, the version number will not be correct in the about dialog etc. -
+semver: minor
to increase the version number - The commit must not be empty (otherwise no build is triggered)
- Without
git push origin main
- git commit with message:\
-
Remove old builds at
/var/www/builds.jabref.org/www/main
and/var/www/builds.jabref.org/www/jdk-ea
. -
Check the Milestone list at https://github.com/JabRef/jabref/milestones
- Go to the milestone of the currently released version.
- Move all open issues to the next milestone
- Close the milestone
- Write a blog entry (at https://github.com/JabRef/blog.jabref.org/).
- Write a news entry at https://discourse.jabref.org/c/news/5
- Follow https://github.com/JabRef/jabref/wiki/Information-update-after-a-release/
- Home
- General Information
- Development
- Please go to our devdocs at https://devdocs.jabref.org
- "Google Summer of Code" project ideas
- Completed "Google Summer of Code" (GSoC) projects
- GSoC 2024 ‐ Improved CSL Support (and more LibreOffice‐JabRef integration enhancements)
- GSoC 2024 - Lucene Search Backend Integration
- GSoC 2024 ‐ AI‐Powered Summarization and “Interaction” with Academic Papers
- GSoC 2022 — Implement a Three Way Merge UI for merging BibTeX entries
- GSoC 2021 - Improve pdf support in JabRef
- GSoC 2021 - Microsoft Word Integration
- GSoc 2019 - Bidirectional Integration — Paper Writing — LaTeX and JabRef 5.0
- GSoC Archive
- Release
- JabCon Archive