Difference between revisions of "Creating Inkscape distributions"

From Inkscape Wiki
Jump to navigation Jump to search
(*Merge the two mentions of doc/keys.html. Typographical: curly quotes for command disambiguation.)
 
(67 intermediate revisions by 15 users not shown)
Line 1: Line 1:
{{Other languages|en=Creating Inkscape distributions}}
== Creating Dists of Inkscape ==
== Creating Dists of Inkscape ==


Those who wish to produce packaged releases of inkscape are welcome to do so.
Those who wish to produce packaged releases of inkscape are welcome to do so.
If it is packages changes that you've made to the official release, please select a
If it is packages changes that you've made to the official release, please select a version name that distinguishes it from the official version, to avoid confusion.  For example, “inkscape-0.35-johndoe.tar.gz”.  Please consider distributing your changes as a patch rather than as a full distribution, as patches tend to be easier to maintain.
version name that distinguishes it from the official version, to avoid confusion.  For
example, “inkscape-0.35-johndoe.tar.gz”.  Please consider distributing your changes
as a patch rather than as a full distribution, as patches tend to be easier to  
maintain.


Inkscape's release process works like this:
Inkscape's release process works like this:


# Start of release process - Finish up work on features.
# Chill - Wrap up development work
# Feature Freeze Mode - Shift focus from feature implementation to bug fixing
# Frost - Feature work should be complete. Bug Hunt
# Feature Freeze - Critical bug fixing
# Hard Freeze - Two freeze wardens are named.  All development must be done as patches submitted to the freeze wardens for review and integration.
# Hard Freeze - Two freeze wardens are named.  All development must be done as patches submitted to the freeze wardens for review and integration.
# Branch - The codebase is tagged and branched.  Final release tarball is posted.  The codebase is returned to regular open development.
# Branch - The codebase is tagged and branched.  Final release tarball is posted.  The codebase is returned to regular open development.
Line 17: Line 16:
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites.  Our Freshmeat record is updated.   
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites.  Our Freshmeat record is updated.   


=== Feature Freeze Mode ===
=== Pre-releases ===


In the run-up to CreatingDists, for a short time preceding the tagging of the release it's a good idea to hold off on adding new features or doing other major changes like architectural changes to the code that might decrease its stability.  Whether a change is minor enough to be “ok” is left to the developer's judgement, and they're trusted to be conservative and careful.
Prior to the release we'll make a series of pre-releases, which give packagers some practice and provide testers and translators with precompiled binaries to do their work with.  This generally follows the regular release process (since it's essentially a dry-run of the release), with a few exceptions.  The process is as follows:


The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, and to do so with the smallest amount of change to the codebase possible.  If a “proper” fix requires architectural changes or redesign of the code, consider writing that up as a post-release task.
ON HEAD:


-----
# Update your git branch to latest, and check that Inkscape configures, builds, and runs
# Set the pre-release version number (see below) to <major>.<minor>pre<prerelease>.  E.g. 0.91pre2
# Create a source tarball package (see below)


It might be useful to branch off a release branch a week before making the release.  Hopefully most people using CVS would switch to this branch at this time.  Then only bug fixes can go into that branch.  --[[Ted]]
=== Creating the Official Release Package ===


At some point prior to the final release, you should establish a release branch, named in the form RELEASE_<major>_<minor>_BRANCH.  For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.  Minor fixes and code review can then be performed on that branch before the final release; it will also be used for making future point releases.


=== Branching the release candidate ===
To create the release branch, do the following:


Before release, a branch should have been be created for that release in the form RELEASE_<major>_<minor>_BRANCH.  For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.
<pre>
  git branch RELEASE_0_38_BRANCH
  git push
</pre>


Minor fixes and code review can then be performed on that branch before the final release; it also permits making future point releases easily (if necessary).
To check out this branch:


To check out the release branch into a fresh working copy, you can use:
<pre>
  git checkout RELEASE_0_38_BRANCH
</pre>


<pre>cvs co -r RELEASE_0_38_BRANCH -d inkscape-0.38-branch inkscape</pre>
After establishing the release branch, set the Inkscape version number in trunk to reflect the new future version, 0.91+devel.


or, if you have a checked out tree handy, it is quicker to use:
Once the release is deemed ready a distribution tarball should be created as below.


<pre>
On the release branch (NOT IN TRUNK):
cp -a inkscape inkscape-0.38-branch
cd inkscape-0.38-branch
cvs up -PAd -r RELEASE_0_38_BRANCH
</pre>


Once the release is deemed ready a distribution tarball should be created as below.
# Set the official release version number (see below) to <major>.<minor> (e.g., 0.91) or <major>.<minor>.0 (e.g., 0.91.0)
# Create a source tarball package (see below)
# GPG sign the source tarball package (see below)


=== Creating a distribution source tarball package ===
=== Setting the Inkscape version number ===


On the release branch (NOT ON HEAD):
Set the version name and number in CMakeList.txt.  For example:


* Set the version name via the file configure.ac in the AC_INIT() macro, Makefile.mingw.common, inkscape.nsi, and in debian/changelog
set(INKSCAPE_VERSION_MAJOR  0)
* Add the release notes into the NEWS file in the release branch
set(INKSCAPE_VERSION_MINOR 92)
* Run ./autogen.sh && ./configure (with any flags, e.g. CXXFLAGS=).
set(INKSCAPE_VERSION_PATCH  1)
* Run “cd src && make helper/sp-marshal.h helper/sp-marshal.cpp inkscape_version.h && perl mkfiles.pl && perl mkdep.pl”, then do “cvs -q diff -du make.*|less” to check for anything strange (e.g. source files accidentally added or removed), and finally “cvs commit -m '' make.*”.
set(INKSCAPE_VERSION_SUFFIX "pre0")
* Make sure the code passes a “make distcheck”
* This should produce inkscape-VERSION.tar.gz
* Commit the changed configure.ac and other files to the branch
* Tag the release in CVS


Release tags should be in the form RELEASE_<major>_<minor>_<point>. A non-point-release like 0.38 would get the tag RELEASE_0_38_0, 0.38.1 would get the tag RELEASE_0_38_1, and so on.
=== Update the translation files ===
This especially must be done when declaring string freeze.
* Run "cd share && make; cd .." to extract needed strings from content files
* Run "cd po && make update-po; cd .." to update the translation files.
* Finally, run "bzr commit -m'update translations'" to commit these changes as well.


On HEAD:
=== Creating a source tarball package ===


* Add the release notes into the NEWS file in the release branch  
* Run `perl packaging/mkNEWS 0.92 > NEWS` to add the release notes into the NEWS file in the release branch. This command requires perl and w3m. Don't forget to replace 0.91 with the correct version number.  The NEWS file may need some manual cleanup, so do a quick review of it.
* Change configure.ac and inkscape_version.h.mingw to reflect the new future version
* mkdir build; cd build; cmake ..; make -j4
* Run "git status" to check for anything strange (e.g. source files accidentally added or removed)
* Run "git commit -am 'Update for ${VERSION} release'" to commit the changed CMakeLists.txt and any other files
* Tag the release in git "git tag.  Release tags should be in the form INKSCAPE_<major>_<minor>_<point>. A non-point-release like 0.91 would get the tag INKSCAPE_0_91_0, 0.91.1 would get the tag INKSCAPE_0_91_1, and so on. Pre-releases are tagged like INKSCAPE_0_92_PRE3 and INKSCAPE_0_92_2_PRE0.
* Run "make dist"
** This should produce inkscape-${VERSION}.tar.bz2 in the build directory
** Verify the cmake output shows WITH_PROFILING and all WITH_*_EXPERIMENTAL tags are OFF
** Verify CMAKE_BUILD_TYPE is set as 'Release'
** Run "tar -C /tmp -xjf inkscape-${VERSION}.tar.bz2" and verify the contents at /tmp/inkscape-${VERSION}/ are as you expect
* Modify CMakeScripts/inkscape-version.cmake to reset INKSCAPE_REVISION to "unknown" [TODO: Replace this substitution with gitattributes]
* git push
* git push origin INKSCAPE_0_92_1_PRE0
* GPG sign the packages (see below)
* Upload the package and sig to the website. (see below)


=== GPG signing Tarballs ===  
=== GPG signing Tarballs ===  
Line 78: Line 96:
* To verify :   
* To verify :   


<pre>$gpg --verify ./tarball.asc ./tarball.tar.gz</pre>
<pre>$gpg --verify ./tarball.sig ./tarball.tar.gz</pre>


Of course, this step doesn't mean much in practice unless people have a trust path to your key.  Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).
Of course, this step doesn't mean much in practice unless people have a trust path to your key.  Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).


:Where are the public keys matching these sig's posted?
Public keys for sigs should be posted to Inkscape's download page, http://inkscape.org/en/download/source/


=== Creating a Windows Distro ===
=== Uploading packages to the website ===
Inkscape/sodipodi has always been
buildable on Win32.  The problem with the sodipodi and original inkscape build, though,
was that the Win32 builder had to download and configure
a lot of things to make it to work.    Mingw, MSYS, automake,
autoconf, pkg-config, the codepages, etc.  He would spend more
time on THAT than the actual code.


What a pain for the average developer/user who merely wants
Releasing on inkscape.org:
to make Inkscape do what he wants it to do. Why waste
days and days getting it to compile, when the developer
would rather be working on the program itself?


So we spent several weeks collecting libraries, building others,
1. First time setup
installing the codepages into the source (which we can delete soon
* Make sure you have a user account on inkscape.org - Go to https://inkscape.org and look in the top right of the page and note your logged in status, use the links provided in the drop down to log in or register an account.
because of Pango) and creating a set of clean makefiles
* Make sure that your account has a big enough quota - Go to https://inkscape.org/user/ and hover over the "Upload Quota" bar, you will only see 10MB if you are a normal user at this time. If you do not see a 2GB quota / are not seeing the 'Uploader' team in your team list, then you need to contact a website admin to put you into the releases group with the larger quota.
that work on Win9x, NT, XP, and the cross-compiler.
* Make sure you have a public gpg key recorded - Go to https://inkscape.org/user/edit/ and fill in the right boxes, the GPG Public Key box is expecting a pasted public key (not private key!) and hit submit when done.
It is a bit more work for people like me, but hopefully it
attains its goal of saving a lot of work for other people.


Also, remember that on Unix/Linux,  $PREFIX is commonly
2. Make a folder for your releases in your 'InkSpace' - Go to https://inkscape.org/gallery/new/ and fill in the name of the folder you want to use, for example "0.92pre2". Set the group to "Developer" to allow other packagers to upload into it, and the category to "Inkscape Package".
/usr/local  or  /usr  or something like that.  On M$, all of
a program's files are typically located in their own directory.  So all
of the files are located relative to “.”. Actually, relative to
the .exe that is currently running.


.....anyway, just wanted to explain that there is a reason
3. Exit this view, by going back to My Galleries (via the resource icon at top right of the screen).  Navigate to the folder you just created (it'll be under the Galleries listing on the lower right).  This should show the information about the gallery you created, along with a blue Submit Resource button.  Click on that button to get to the Upload New Resource dialog for your gallery.
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.


Once the tree is built (“make -f Makefile.mingw” and “make -f Makefile.mingw dist”) into the “inkscape” directory, the [http://nsis.sourceforge.net/ NSIS] installer script “inkscape.nsi” can be run to create the self-extracting installer.
* Ignore 'External Link'
* Going into the editor section you should be able to fill in the title for the released file.  E.g. "Inkscape 0.92pre2 Source Tarball"
* Select 'Inkscape Package' from the category drop down.
* Upload the gpg sig file using the 'Choose File' button under Signature/Checksum.
* Select 'GPLv2' (or 'GPLv3' if appropriate) from the Licenses drop down.
* Check 'Mirror' checkbox (optional; not used presently)
* Submit this form.


The Windows download package should be named according to the following scheme:
5. Verify and copy link - If everything's gone well you should now see your released file with a blue ribbon icon indicating the gpg signature has been verified against your account public key.
* Download the release by clicking on the down-arrow icon. Confirm it's the file you intended.
* Copy this download link.


    inkscape-$RELEASE-$PKG.$WINVER.exe
6. Link from the downloads page.
* For this step you will need CMS editor access or pass this task onto a website editor and/or translator.
* Go to the Source download page and click edit
* In the appropriate section for the download link, insert a 'Link' CMS Plugin
* Edit the downloads pages for the right OS and update with the right version, release and other details as you would want it to be presented to users. Add the copied link into the right place.
* Save /and/ then hit the blue publish button.


Where $WINVER is the required Windows version, e.g. “win32”. For example:
Congratulations, you've uploaded, released and published your release file.


    inkscape-0.37-1.win32.exe
=== Update Release Data in Launchpad ===


The release packages are also uploaded at launchpad.net by the Inkscape Launchpad Admins.


=== Creating a Debian .deb ===
* From https://launchpad.net/inkscape, under Series and Milestones click the appropriate release series (e.g. 0.91.x)
* Change the development branch from Pre-release Freeze (or whatever) to Current Stable Release
* Make sure there is an existing Milestone entry under Milestones and releases for this release number; if not, add it
* Click on 'Release now' to set a release date.  Paste in the Informal Release Announcement to Release Notes, and the NEWS file as ChangeLog.
* Click on 'Add download file' to add the source tarballs and signatures.  Set their Description to "Inkscape Source Package (gz)", etc.
* Set the previous Current Stable Release to Obsolete (or Supported if there are any further plans for point releases.)


The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.
=== Creating a Windows Distribution with Installer ===


=== Creating a distribution RPM ===
See [[Compiling Inkscape on Windows]], specifically the section on [[Compiling Inkscape on Windows#Creating an installer|Creating an installer]].


Method A:
=== Creating a Debian .deb ===
# do as above for tarball, or download the release tarball
# login as root
# rpmbuild -tb inkscape-x.x.tar.gz
# Your RPMs will be in /usr/src/rpm/RPMS (/usr/src/redhat on RH systems)
# RPMs should be GPG signed


Method B:
The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.
# do as above for tarball, or download the release tarball
# mkdir ~/rpm
# Copy the tarball to ~/rpm/SOURCES/
# Copy the inkscape.spec from the tarball to ~/rpm/SPECS/inkscape.spec
# rpmbuild -ba ~/rpm/SPECS/inkscape.spec
# Your RPMs will be in ~/rpm/RPMS and ~/rpm/SRPMS
# RPMs should be GPG signed
 
The rpm should be named according to the following pattern:
 
  inkscape-$RELEASE-$PKG.$DISTRO.$ARCH.rpm
 
Where:
 
$RELEASE: the Inkscape release number, such as “0.37”, “0.36.2”, etc. 
The third number should be omitted if it is 0.  (I.e., 0.37 instead of 0.37.0)
 
$PKG:  A version number for your package.  Use a value of 1 for your package, and increment it if you
need to update the released package for some reason.
 
$DISTRO:  The name and an indicator of the version number for the distro.  E.g.,
rh71, rh90, mdk91, suse90, fc1, etc.  No need to be too exhaustive with the distro versions;
for a given brand of distro it's probably enough to have a reasonably “modern” release
and an older one for legacy support.  For instance, rh71 and rh90.
 
$ARCH:  The architecture that the package was built on.  E.g., i686, i386, athlon, ppc, etc.
Don't bother with i586 - either i386 or i686 is preferred.  The i386 packages will run on Cyrix
and K-6.
 
Examples:
 
  inkscape-0.37-1.mdk80.i386.rpm
  inkscape-0.37-1.mdk80.i686.rpm
  inkscape-0.37-1.mdk91.i386.rpm
  inkscape-0.37-1.mdk91.i686.rpm


  inkscape-0.37-1.fc1.i386.rpm
  inkscape-0.37-1.fc1.i686.rpm
  inkscape-0.37-1.fc1.athlon.rpm
  inkscape-0.37-1.fc1.ppc.rpm
For creating spec files, feel free to list yourself as the packager, but please use
inkscape-devel@lists.sourceforge.net as the contact email address, to ensure that
questions/complaints about the RPM go to the official support channel.
==== Patching RPMs ====
Occasionally, the RPM will not build without some modifications.  If the problem is serious enough that it affects every packaging format, this could signal a need to do a point release, but usually you can just add a patch specifically for the RPM.  This is what RPM is for, after all.  :-)
Here's how to do it:
1.  Create a copy of the source tree, with the modifications needed to correct the issue.
2.  Generate a patch like this:
  $ diff -uNr package-1.0/ package-1.0p/ > ../SOURCES/package-1.0-my.patch
3.  Next add the patch to the RPM.  In the specfile at %_topdir/SPECS/package.spec, add a line like this at the top of the file:
  Patch0: package-1.0-my.patch
Then further down add a line after the %setup section, like this:
  %prep
  %setup ...
  %patch0 -p1
It's a very good idea to split up changes into discrete patches, giving each a different number (they don't have to be consecutively numbered).  Also, be sure to upload the patch(es) to the patch tracker so they'll get into the codebase for the next release.
Then rebuild the package like this:
  rpmbuild -ba SPECS/package.spec
=== Signing your package ===
First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'.
To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign
To check the signature on a package, use rpm --checksig.
=== Releasing Dists on the SourceForge File Release Tool ===
To release a file:  (You need Release Tech permission for your Inkscape account)
* ftp upload.sf.net  (anonymous/anonymous)
* cd incoming
* mput filename
* go to Admin -> File Releases
* scroll to the bottom and click [Add Release] to the inkscape item
* Enter 0.35 in the box & click “Create this Release”
* Fill in the form, checkbox the file you uploaded in (c)
* It won't give you a clear “success” message, but you can check it got in right by going to the Files list.  You can then edit any of the info you entered, to make it more correct.
Also see CVSNamingConventions if you are making a release.




Line 241: Line 162:
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list.  This is done by a list admin such as Bryce Harrington.
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list.  This is done by a list admin such as Bryce Harrington.


'''[AnnouncingReleases Places to Submit Release Announcements]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).
'''[[AnnouncingReleases]]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).
 
 


=== Updating Website Collateral ===
=== Updating Website Collateral ===


When a new release is cut, there are several pieces of info that need to be added to the website:
When a new release is cut, there are several pieces of info that need to be added to the website:
Line 255: Line 173:
* Add or revise Screenshots (if appropriate)
* Add or revise Screenshots (if appropriate)
* doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
* doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
** From shell.sf.net, cd to the inkscape_web directory and run the command “(cd ../inkscape; cvs update;chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.
** From the shell on inkscape.org, cd to /home/inkscape/inkscape_web and run the command “(cd ../inkscape; svn update; chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.
* Review/revise links to keys.html
[[Category:Help Wanted]]

Latest revision as of 10:33, 7 August 2017

Other languages: العربية Català Česky Deutsch English Español Français Italiano 日本語 한국어 Polski Português Português do Brasil Русский Slovenčina 中文

Creating Dists of Inkscape

Those who wish to produce packaged releases of inkscape are welcome to do so. If it is packages changes that you've made to the official release, please select a version name that distinguishes it from the official version, to avoid confusion. For example, “inkscape-0.35-johndoe.tar.gz”. Please consider distributing your changes as a patch rather than as a full distribution, as patches tend to be easier to maintain.

Inkscape's release process works like this:

  1. Chill - Wrap up development work
  2. Frost - Feature work should be complete. Bug Hunt
  3. Feature Freeze - Critical bug fixing
  4. Hard Freeze - Two freeze wardens are named. All development must be done as patches submitted to the freeze wardens for review and integration.
  5. Branch - The codebase is tagged and branched. Final release tarball is posted. The codebase is returned to regular open development.
  6. Packaging - Three days are allowed for creating release dists (rpm's, deb's, exe's, and autopackages).
  7. Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites. Our Freshmeat record is updated.

Pre-releases

Prior to the release we'll make a series of pre-releases, which give packagers some practice and provide testers and translators with precompiled binaries to do their work with. This generally follows the regular release process (since it's essentially a dry-run of the release), with a few exceptions. The process is as follows:

ON HEAD:

  1. Update your git branch to latest, and check that Inkscape configures, builds, and runs
  2. Set the pre-release version number (see below) to <major>.<minor>pre<prerelease>. E.g. 0.91pre2
  3. Create a source tarball package (see below)

Creating the Official Release Package

At some point prior to the final release, you should establish a release branch, named in the form RELEASE_<major>_<minor>_BRANCH. For example, 0.38 should have a branch called RELEASE_0_38_BRANCH. Minor fixes and code review can then be performed on that branch before the final release; it will also be used for making future point releases.

To create the release branch, do the following: 

  git branch RELEASE_0_38_BRANCH
  git push

To check out this branch: 

  git checkout RELEASE_0_38_BRANCH

After establishing the release branch, set the Inkscape version number in trunk to reflect the new future version, 0.91+devel.

Once the release is deemed ready a distribution tarball should be created as below.

On the release branch (NOT IN TRUNK):

  1. Set the official release version number (see below) to <major>.<minor> (e.g., 0.91) or <major>.<minor>.0 (e.g., 0.91.0)
  2. Create a source tarball package (see below)
  3. GPG sign the source tarball package (see below)

Setting the Inkscape version number

Set the version name and number in CMakeList.txt. For example: 

set(INKSCAPE_VERSION_MAJOR  0)
set(INKSCAPE_VERSION_MINOR 92)
set(INKSCAPE_VERSION_PATCH  1)
set(INKSCAPE_VERSION_SUFFIX "pre0")

Update the translation files

This especially must be done when declaring string freeze.

  • Run "cd share && make; cd .." to extract needed strings from content files
  • Run "cd po && make update-po; cd .." to update the translation files.
  • Finally, run "bzr commit -m'update translations'" to commit these changes as well.

Creating a source tarball package

  • Run `perl packaging/mkNEWS 0.92 > NEWS` to add the release notes into the NEWS file in the release branch. This command requires perl and w3m. Don't forget to replace 0.91 with the correct version number. The NEWS file may need some manual cleanup, so do a quick review of it.
  • mkdir build; cd build; cmake ..; make -j4
  • Run "git status" to check for anything strange (e.g. source files accidentally added or removed)
  • Run "git commit -am 'Update for ${VERSION} release'" to commit the changed CMakeLists.txt and any other files
  • Tag the release in git "git tag. Release tags should be in the form INKSCAPE_<major>_<minor>_<point>. A non-point-release like 0.91 would get the tag INKSCAPE_0_91_0, 0.91.1 would get the tag INKSCAPE_0_91_1, and so on. Pre-releases are tagged like INKSCAPE_0_92_PRE3 and INKSCAPE_0_92_2_PRE0.
  • Run "make dist"
    • This should produce inkscape-${VERSION}.tar.bz2 in the build directory
    • Verify the cmake output shows WITH_PROFILING and all WITH_*_EXPERIMENTAL tags are OFF
    • Verify CMAKE_BUILD_TYPE is set as 'Release'
    • Run "tar -C /tmp -xjf inkscape-${VERSION}.tar.bz2" and verify the contents at /tmp/inkscape-${VERSION}/ are as you expect
  • Modify CMakeScripts/inkscape-version.cmake to reset INKSCAPE_REVISION to "unknown" [TODO: Replace this substitution with gitattributes]
  • git push
  • git push origin INKSCAPE_0_92_1_PRE0
  • GPG sign the packages (see below)
  • Upload the package and sig to the website. (see below)

GPG signing Tarballs

Downstream packagers are asking for and may soon demand gpg signed tarballs. For Fedora, this is not a requirement, but does ease acceptance of packages. It also shows we are doing “The Right Thing”. md5sums are not foolproof.

  • To create a gpg signed tarball:
$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz
  • To verify :
$gpg --verify ./tarball.sig ./tarball.tar.gz

Of course, this step doesn't mean much in practice unless people have a trust path to your key. Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).

Public keys for sigs should be posted to Inkscape's download page, http://inkscape.org/en/download/source/

Uploading packages to the website

Releasing on inkscape.org:

1. First time setup

  • Make sure you have a user account on inkscape.org - Go to https://inkscape.org and look in the top right of the page and note your logged in status, use the links provided in the drop down to log in or register an account.
  • Make sure that your account has a big enough quota - Go to https://inkscape.org/user/ and hover over the "Upload Quota" bar, you will only see 10MB if you are a normal user at this time. If you do not see a 2GB quota / are not seeing the 'Uploader' team in your team list, then you need to contact a website admin to put you into the releases group with the larger quota.
  • Make sure you have a public gpg key recorded - Go to https://inkscape.org/user/edit/ and fill in the right boxes, the GPG Public Key box is expecting a pasted public key (not private key!) and hit submit when done.

2. Make a folder for your releases in your 'InkSpace' - Go to https://inkscape.org/gallery/new/ and fill in the name of the folder you want to use, for example "0.92pre2". Set the group to "Developer" to allow other packagers to upload into it, and the category to "Inkscape Package".

3. Exit this view, by going back to My Galleries (via the resource icon at top right of the screen). Navigate to the folder you just created (it'll be under the Galleries listing on the lower right). This should show the information about the gallery you created, along with a blue Submit Resource button. Click on that button to get to the Upload New Resource dialog for your gallery.

  • Ignore 'External Link'
  • Going into the editor section you should be able to fill in the title for the released file. E.g. "Inkscape 0.92pre2 Source Tarball"
  • Select 'Inkscape Package' from the category drop down.
  • Upload the gpg sig file using the 'Choose File' button under Signature/Checksum.
  • Select 'GPLv2' (or 'GPLv3' if appropriate) from the Licenses drop down.
  • Check 'Mirror' checkbox (optional; not used presently)
  • Submit this form.

5. Verify and copy link - If everything's gone well you should now see your released file with a blue ribbon icon indicating the gpg signature has been verified against your account public key.

  • Download the release by clicking on the down-arrow icon. Confirm it's the file you intended.
  • Copy this download link.

6. Link from the downloads page.

  • For this step you will need CMS editor access or pass this task onto a website editor and/or translator.
  • Go to the Source download page and click edit
  • In the appropriate section for the download link, insert a 'Link' CMS Plugin
  • Edit the downloads pages for the right OS and update with the right version, release and other details as you would want it to be presented to users. Add the copied link into the right place.
  • Save /and/ then hit the blue publish button.

Congratulations, you've uploaded, released and published your release file.

Update Release Data in Launchpad

The release packages are also uploaded at launchpad.net by the Inkscape Launchpad Admins.

  • From https://launchpad.net/inkscape, under Series and Milestones click the appropriate release series (e.g. 0.91.x)
  • Change the development branch from Pre-release Freeze (or whatever) to Current Stable Release
  • Make sure there is an existing Milestone entry under Milestones and releases for this release number; if not, add it
  • Click on 'Release now' to set a release date. Paste in the Informal Release Announcement to Release Notes, and the NEWS file as ChangeLog.
  • Click on 'Add download file' to add the source tarballs and signatures. Set their Description to "Inkscape Source Package (gz)", etc.
  • Set the previous Current Stable Release to Obsolete (or Supported if there are any further plans for point releases.)

Creating a Windows Distribution with Installer

See Compiling Inkscape on Windows, specifically the section on Creating an installer.

Creating a Debian .deb

The article CompilingDebian provides a makefile to download a tarball and build a debian package therefrom.


Announcing Releases

When you cut a release, send a copy of the release notes as an announcement to inkscape-announce@lists.sourceforge.net. If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list. This is done by a list admin such as Bryce Harrington.

AnnouncingReleases - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).

Updating Website Collateral

When a new release is cut, there are several pieces of info that need to be added to the website:

  • Add a news item on front page
  • Review/revise FAQ
  • Review/revise Roadmap
  • Add or revise Screenshots (if appropriate)
  • doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
    • From the shell on inkscape.org, cd to /home/inkscape/inkscape_web and run the command “(cd ../inkscape; svn update; chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.
  • Review/revise links to keys.html
Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=Creating_Inkscape_distributions&oldid=106236"