Jump to content

KDevelop/Release Process: Difference between revisions

From KDE Community Wiki
Kfunk (talk | contribs)
Improve command listing
Milian (talk | contribs)
 
(9 intermediate revisions by 4 users not shown)
Line 6: Line 6:


(all commands are fish commands, adapt as needed)
(all commands are fish commands, adapt as needed)
* For kdevelop, kdev-python, kdev-php: go to stable branch, don't forget to pull, edit CMakeLists.txt with the new version number. Don't create a tag. Commit and push.
* For kdevelop, kdev-python, kdev-php:
* Create tarballs and tags with releaseme:  
** go to stable branch, e.g.: <code>git checkout 5.6</code>
** 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
** don't forget to pull: <code>git pull --rebase</code>
* Sign:
** edit CMakeLists.txt with the new version number, e.g.: <code>project(KDevelop VERSION 5.6.1)</code>
** for file in *.tar.xz; gpg --detach-sign --armor $file; end
** 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>
* When built, get the AppImage: http://home.kfunk.org:8080/job/kdevelop-appimage-centos/
** Don't create a tag. Commit and push.
* Create tarballs and tags with releaseme:
 
    VERSION=5.6.1
    cs releaseme
    for application in kdev-python kdev-php kdevelop; do
        ./tarme.rb --version $VERSION --origin stable $application
        ./tagme.rb --version $VERSION
    done
 
* Update version.ini to have the new tarball version and default target, commit and push:
* Update version.ini to have the new tarball version and default target, commit and push:
** kde:craft-blueprints-kde/extragear/kdevelop/version.ini  
** kde:craft-blueprints-kde/extragear/kdevelop/version.ini  
* When built, get the new windows installers:
* Build AppImage locally, using https://invent.kde.org/mwolff/kf5-appimage-centos7/-/tree/master/ , then sign:
** https://binary-factory.kde.org/job/KDevelop_Release_win32/
** gpg2 --armor --detach-sign -o KDevelop-$VERSION-x86_64.AppImage.sig KDevelop-$VERSION-x86_64.AppImage
* When built, get the new windows installers (needs someone to confirm they work):
** https://binary-factory.kde.org/job/KDevelop_Release_win64/
** https://binary-factory.kde.org/job/KDevelop_Release_win64/
* Upload all of them either using ftp + filing a sysadmin ticket, or directly: make directory structure, sign files, then
* Upload all of them either using ftp + filing a sysadmin ticket, or directly: see "Self-Uploading to Download Server"
 
    VERSION=5.6.1
    kdecp5 kdev*$VERSION*.xz{,.sig} ftp://upload.kde.org/incoming


* 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
  # 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"
  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 *AppImage* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/bin/linux/
scp *.tar.xz* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/src/
  scp *.exe* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/bin/windows/
  scp *.exe* [email protected]:/home/ftpadmin/stable/kdevelop/$VERSION/bin/windows/


Line 30: Line 49:
This checklist should be processed in the respective order.
This checklist should be processed in the respective order.


* When release date is clear, email release-team@
* When release date is clear, email release-team@ and translators [email protected]


* Website
* Website
Line 65: Line 84:


* Optional stuff
* Optional stuff
** Update Wikipedia (release date, feature comparison)
** 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 screenshots (website, kde.org, kde-apps, freshmeat, facebook)
** Update OpenHub (app icon/logo)
** Update OpenHub (app icon/logo)

Latest revision as of 20:07, 11 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.
  • Create tarballs and tags with releaseme:
   VERSION=5.6.1
   cs releaseme
   for application in kdev-python kdev-php kdevelop; do
       ./tarme.rb --version $VERSION --origin stable $application
       ./tagme.rb --version $VERSION
   done
   VERSION=5.6.1
   kdecp5 kdev*$VERSION*.xz{,.sig} ftp://upload.kde.org/incoming
  • 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.

  • 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

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:

Also add the sha256sum of the tarballs to the sysadmin ticket; also tell where sysadmins should upload the tarballs.