more frequent releases

[nodiscc]

Hello, this was discussed at #505 . I think having a shell/python script that would build the XPI from the development tree would be nice. It could be made usable from common GNU/Linux distributions setups (install dependencies, run tests, build) so that testers can build the latest version easily and @myrdd does not have to build himself and create a github release.

An online build service is another option, i don't know if it involves more work/is more practical.

[myrdd]

Currently you can use ant for building. Don't you use that already? See https://github.com/RequestPolicyContinued/requestpolicy/wiki/Setting-up-a-development-environment#building-the-extension-xpi

ant is going to be replaced by make, see https://github.com/RequestPolicyContinued/requestpolicy/blob/dev-restartless/src/Makefile

Yes, running tests using make is another issue.

[nodiscc]

I've just built the addon XPI successfully, but had to install the ant openjdk-7-jdk packages (this is not documented). I used to stick to the latest build in https://github.com/RequestPolicyContinued/requestpolicy/releases. I think most testers so the same. The download link on the site points to this build so this is natural. (should we point the "beta" download link to the build instructions?)

Is it time to release 1.0.0b8 ? There have been many changes since the last release v1.0.0b7...dev-1.0

[myrdd]

@nodiscc if you think we should publish a new release, I see no problem with that. We will probably reach 1.0beta20 before the first stable if we want to publish releases frequently, but that should be no problem. What do you think?
Most changes since 1.0.0b7 have been refactoring though.

[myrdd]

IMHO we should at least move the subscriptions to github (#494) and apply pull request #506.

had to install the ant openjdk-7-jdk packages

yes, as make is much more common, I'll change to that built system.

[nodiscc]

Let's move the subscriptions to github then. Thanks for merging #506.

We will probably reach 1.0beta20 before the first stable if we want to publish releases frequently

No problem for me either. This way more people will be beta testing the recent changes (and there will be less bug reports against already fixed bugs).

make is much more common, I'll change to that built system

Great. Then I'd like to update the wiki with "How to help testing" (download the release or follow build instructions, find bugs, try to reproduce in new profile with no addons, attach browser version to bug report...).

I think the update path should also be sorted out before the release.

• Now that installing the XPI from github works, we can link the site's download button directly to the XPI. done
• https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io/blob/master/xpi/update-1.x-beta.rdf can be moved to the main repo
• <em:updateURL> in https://github.com/RequestPolicyContinued/requestpolicy/blob/dev-1.0/src/install.rdf should point to the new update rdf location.

Maybe it's ok to close this bug or retitle it "more frequent releases"? It's not about about a build service

[nodiscc]

A dirty shell script to automate the release process.

#!/bin/bash
set -e

## config
my_gpg_keyid="F713697B"
new_release="v1.0.0b8"
previous_release="1.0.0b7"
changelog='
 * 7ceef9f query interface when using aContext, fixes #503
 * df602e7 rewrote readme.md a little
 * ec9268b add mozmill test testPolicy/testIframeTree/testDefaultPolicies.js
 * e164b2c update italian translation'

## bump version number in install.rdf
sed -i "s/$previous_release/$new_release/g" install.rdf
echo 'You have to edit manually em:updateLink in update-1.x-beta.rdf for now.'
echo 'URL format should be https://github.com/RequestPolicyContinued/requestpolicy/releases/download/$new_release/requestpolicy-$new_release.xpi'

# build
ant
mv "dist/requestpolicy.xpi dist/requestpolicy-$new_release.xpi"

#TODO: Get certificate from https://en.sklep.unizeto.pl/test_certificates
#TODO: SIGN the XPI


#add changes, generate sha512, add it to commit message
git add install.rdf
git add ../update-1.x-beta.rdf
xpi_sha512=$(sha512sum "dist/requestpolicy-$new_release.xpi")
release_message="Release RequestPolicy Continued $new_release
The attached XPI file has a SHA512 sum of $xpi_sha512
$changelog"
git commit -m "$release_message" --gpg-sign="$my_gpg_keyid"

## tag with gpg signature
git tag --sign -u "$my_gpg_keyid" "$new_release" -m "$release_message"

echo 'Now you can push the commit and tag (git push --tags), go to https://github.com/RequestPolicyContinued/requestpolicy/releases, create a new release for this tag, and attach your XPI file to it.'
echo "Don't forget to update the download link on the website."

Read before you run.

[myrdd]

Let's move the subscriptions to github then.

done.

Then I'd like to update the wiki […]

Great! Contributions to the wiki are appreciated!

https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io/blob/master/xpi/update-1.x-beta.rdf can be moved to the main repo

sadly no. A http request to the raw github file still sends Content-Type: text/plain; charset=utf-8, but it must be application/rdf+xml, which is correct for the same file via github.io. You can test this with Firefox' built-in Network Monitor.

btw, just go ahead if you want to rename issues @nodiscc :)

@nodiscc nice bash script. I'll see if I can use it.

[nodiscc]

A http request to the raw github file still sends Content-Type: text/plain; charset=utf-8, but it must be application/rdf+xml

Thanks for unconfusing me.

[myrdd]

We're almost ready to release beta8.

@nodiscc I'll follow your description at #484 (comment), but I don't have a gpg key for dev(at)256k(dot)de yet, so I'll create one. However, where should I put the public key? Putting it in the readme as you've suggested makes no sense to me, does it? We could put it on the website maybe. A key server would make key signing possible/easier though. What do you think?

[nodiscc]

You're right, putting it in the README makes no sense (or anywhere in the organization's repos). Using keyservers is the way to go.

Example: gpg --send-keys $key_id --keyserver $keyserver_url
A few keyservers I found: hkp://subkeys.pgp.net, hkp://pool.sks-keyservers.net, ldap://keyserver.pgp.com, https://pgp.mit.edu/ (web-based key submission). Once you publish it it would be nice to have it signed by many people. Please pick a nice long password and keep the revocation certificate :)

[myrdd]

Thanks for your advice @nodiscc

[myrdd]

v1.0.beta8 is released, see here: #484 (comment)

I still need to get certificate, but this is tracked in #465, so I'll close this issue.