KDevelop/Release Process: Difference between revisions
Appearance
< KDevelop
mNo edit summary |
m →HowTo |
||
Line 7: | Line 7: | ||
(all commands are fish commands, adapt as needed) | (all commands are fish commands, adapt as needed) | ||
* For kdevelop, kdev-python, kdev-php: | * For kdevelop, kdev-python, kdev-php: | ||
** go to stable branch | ** go to stable branch, e.g.: <code>git checkout 5.6</code> | ||
** don't forget to pull | ** don't forget to pull: <code>git pull --rebase</code> | ||
** edit CMakeLists.txt with the new version number | ** edit CMakeLists.txt with the new version number, e.g.: <code>project(KDevelop VERSION 5.6.1)</code> | ||
** edit <code>org.kde.*.metainfo.xml</code> and add a short release note, e.g.: <code><release version="5.6.1" date="2020-12-08"/></code> | |||
** Don't create a tag. Commit and push. | ** Don't create a tag. Commit and push. | ||
* Create tarballs and tags with releaseme: | * Create tarballs and tags with releaseme: |
Revision as of 17:30, 8 December 2020
Release process for publishing a new KDevelop version
HowTo
This list explains how to obtain release artifacts.
(all commands are fish commands, adapt as needed)
- For kdevelop, kdev-python, kdev-php:
- go to stable branch, e.g.:
git checkout 5.6
- don't forget to pull:
git pull --rebase
- edit CMakeLists.txt with the new version number, e.g.:
project(KDevelop VERSION 5.6.1)
- edit
org.kde.*.metainfo.xml
and add a short release note, e.g.:<release version="5.6.1" date="2020-12-08"/>
- Don't create a tag. Commit and push.
- go to stable branch, e.g.:
- Create tarballs and tags with releaseme:
- set VERSION 5.2.4; for application in kdev-python kdev-php kdevelop; ruby tarme.rb --version $VERSION --origin stable $application; ruby tagme.rb --version $VERSION; end
- repos on invent.kde.org are not yet supported by tagme.rb it seems, set tag manually: git tag -s -m "Tagging $VERSION" v$VERSION <commit-id>, then git push to invent.kde.org
- Build AppImage locally, using appimage/README.md in the sources as guide, then sign:
- gpg2 --armor --detach-sign -o KDevelop-$VERSION-x86_64.AppImage.sig KDevelop-$VERSION-x86_64.AppImage
- Update version.ini to have the new tarball version and default target, commit and push:
- kde:craft-blueprints-kde/extragear/kdevelop/version.ini
- When built, get the new windows installers (needs someone to confirm they work):
- Upload all of them either using ftp + filing a sysadmin ticket, or directly: see "Self-Uploading to Download Server"
- check Stable builds on binary-factory.kde.org to cover the current stable branch
- adapt sysadmin/binary-factory-tooling/craft/enabled-projects.yaml
Self-Uploading to Download Server
set VERSION 5.2.4 # on milonia make the new release directory ssh [email protected] "mkdir -p /home/ftpadmin/stable/kdevelop/$VERSION/src && mkdir -p /home/ftpadmin/stable/kdevelop/$VERSION/bin/linux && mkdir -p /home/ftpadmin/stable/kdevelop/$VERSION/bin/windows" scp *.tar.xz* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/src/ scp *AppImage* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/bin/linux/ scp *.exe* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/bin/windows/
Checklist
This list explains how to perform the release from the management point of view. This checklist should be processed in the respective order.
- When release date is clear, email release-team@ and translators [email protected]
- Website
- Prepare release announcement for kdevelop.org (don't publish yet)
- Repositories (needs to be done for each repository we release)
- Verify unit tests are working
- Using the ReleaseMe script (see next paragraph)
- Generate tarballs
- Tag the version
- Adjust codebase for next dev cycle
- Bugzilla
- Add new versions in bugzilla
- Add new milestones in bugzilla
- Pre-Publishing
- Alert KDE Promo team to forthcoming release announce #kde-promo or Telegram group
- Upload tarball to KDE FTP (see ftp://upload.kde.org/README)
- File sysadmin ticket to publish files, specify directory should be kept hidden
- Wait for it to be uploaded
- e-mail release-team@ to tell distros to start packaging
- Publishing
- File sysadmin ticket to publish files publically, chmod 755 the download directory on milonia
- When files are uploaded
- Update download page on the website (https://www.kdevelop.org/download)
- Publish release announcement on the website
- Coordinate with KDE Promo team putting on social media and Dot as appropriate
- Share blog post on Reddit/Hackernews/Twitter/whatever
- Mail release announcement to kde-announce-apps@ & kdevelop@ & kdevelop-devel@
- Update IRC channel topic
- Optional stuff
- Update Wikipedia (release date, feature comparison): https://www.wikidata.org/wiki/Q468841, https://en.wikipedia.org/wiki/KDevelop
- Update screenshots (website, kde.org, kde-apps, freshmeat, facebook)
- Update OpenHub (app icon/logo)
More information can be found here: https://community.kde.org/ReleasingSoftware
Using ReleaseMe
Setup:
git clone kde:releaseme cd releaseme cat README.md
Step 1: tarballing
./tarme.rb --version 5.3 --origin 5.3 kdevelop
Step 2: tagging
./tagme.rb 5.3.0
Rinse & repeat for kdev-php, kdev-python
Upload the tarballs to the KDE FTP and notify the sysadmins:
- Upload to ftp://upload.kde.org:21/incoming/
- Create one ticket at https://phabricator.kde.org/maniphest/task/edit/form/2/
Also add the sha256sum of the tarballs to the sysadmin ticket; also tell where sysadmins should upload the tarballs.
- Example destination: http://download.kde.org/stable/kdevelop/5.3.0/src/