AnnouncementPR

2004-07-17T17:24:16Z

65.126.45.54: *

Inkscape PR Release by Release should go here:

----

Replace me with real content.

AnnouncementPR

2004-07-17T17:22:27Z

65.126.45.54: added content

Inkscape PR Release by Release should go here:

====

Replace me with real content.

Creating Inkscape distributions

2004-07-17T17:09:13Z

65.126.45.54: added pr page

== 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.

=== Feature Freeze Mode ===

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.

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.

-----

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]]

=== Branching the release candidate ===

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.

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 the release branch into a fresh working copy, you can use:

<pre>cvs co -r RELEASE_0_38_BRANCH -d inkscape-0.38-branch inkscape</pre>

or, if you have a checked out tree handy, it is quicker to use:

<pre>
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.

=== Creating a distribution source tarball package ===

On the release branch:

* Set the version name via the file configure.in in the AC_INIT() macro
* Set the inkscape.spec.in to have the release at ‘1’ instead of ‘CVS’
* Add the release notes into the NEWS file in the release branch
* Run ./autogen.sh
* Run perl mkfiles.pl && perl mkdep.pl && cvs commit -m '' make.*
* Make sure the code passes a ‘make distcheck’
* This should produce inkscape-VERSION.tar.gz
* Commit the changed configure.in 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.

On HEAD:

* Add the release notes into the NEWS file in the release branch
* Change configure.in and inkscape.spec.in to reflect the new future version

=== 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:

<pre>$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz</pre>

* To verify :

<pre>$gpg --verify ./tarball.asc ./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).

:Where are the public keys matching these sig's posted?

=== Creating a Windows Distro ===

IS/SP has always been
buildable on Win32. The problem with the SP 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
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,
installing the codepages into the source (which we can delete soon
because of Pango) and creating a set of clean makefiles
that work on Win9x, NT, XP, and the Linux cross-compiler.
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
/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
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.

The Windows download package should be named according to the following scheme:

inkscape-$RELEASE-$PKG.$WINVER.exe

Where $WINVER is the required Windows version, e.g. "win32". For example:

inkscape-0.37-1.win32.exe

=== Creating a Debian .deb ===
* Do as above for tarball
* Ensure that debian/changelog is up-to-date. (The version number is taken from this changelog.) If making a new entry, then look at the release notes and consider mentioning a couple of notable changes in the new dechangelog entry.
* Run ‘fakeroot ./debian/rules binary’

Name the debian package according to the following scheme:

inkscape-$RELEASE-$PKG.$ARCH.deb

For example:

inkscape-0.37-1.i386.deb
inkscape-0.37-1.athlon.deb
inkscape-0.37-1.ppc.deb
inkscape-0.37-1.sparc.deb

[Can someone confirm the above? The standard names produced by ‘debian/rules binary’ would be e.g. ‘inkscape_0.37-1.i386.deb’.]
=== Creating a distribution RPM ===
* do as above for tarball
* rpmbuild -tb inkscape-x.x.tar.gz
* Your RPMs will be in /usr/src/rpm/RPMS (/usr/src/redhat on RH systems)
* RPMs should to 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.

=== 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.

=== AnnouncementPR ===

Yes, writing great press releases for the project is absolutely vital.

=== 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 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!).

=== 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)
* Add the manpage for the release
** From shell.sf.net, cd to the inkscape_web directory and run the command ‘pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape.html’.

Inkscape Wiki - User contributions [en]

AnnouncementPR

AnnouncementPR

Creating Inkscape distributions