Investigate whether down-stream ike-scan packager changes should be included

[claudijd]

I was poking around to see what other OS variants package ike-scan and noticed that Ubuntu is running 1.9-4, which appears to be a forked version 1.9.0 with some updates.

It might be worth reviewing their diffs to see if it makes sense to bring them up into this version.

http://packages.ubuntu.com/lucid/ike-scan
http://archive.ubuntu.com/ubuntu/pool/universe/i/ike-scan/ike-scan_1.9-4.diff.gz

[claudijd]

Also, since there a lot of updates between 1.9.0 and development HEAD (1.9.3+), we might consider just rev'ing the release and trying to notify the Linux distribution channels of the new source code distribution location so they can start using the latest.

[royhills]

Thanks for spotting the Ubuntu diff. Most of the changes are debian/ubuntu packaging stuff, but there's one change to fix a debian bug which I've addressed in git.

You're right. It probably is time to do a release. I guess we could use github's release system for this, rather than the old "put the tarball on my website" method that I used to use.

Linked to this is whether I should move the ike-scan homepage to use github pages. I've seen some projects that use these, and they look quite decent. We could then have links to downloads for those people who just want to get the latest stable source (probably most people).

The current homepage is here. Pretty basic I think you'll agree.
http://www.nta-monitor.com/tools-resources/security-tools/ike-scan

[claudijd]

Yeah, I think we could easily port the existing home page to a github page or the built in wiki.

As for a release process that is Git friendly, I would recommend we consider just using simple tagging.

Once that is done, not only can people checkout the source code, but they will also have the option in Git to checkout older versions for testing. Additionally, you get "automagic" zip/tar.gz support for free on each tag.

Here's an example from one of my ruby projects so you can see what we can expect...

https://github.com/claudijd/c7decrypt/releases

We'll probably also want to go back and retroactively tag all prior releases so we can provide a full history of releases for the project.

[claudijd]

I just tagged all the historical releases so you can now see them here:

https://github.com/royhills/ike-scan/releases

Next time one of us tags a release, here's the command to do so...

git tag -a [VERSION] [COMMIT_HASH] -m "Tagging [VERSION] Release"
git push --tags

Items above in brackets need to be replaced with the respective version and commit hash.

Here's an example of one of the ones I did....

git tag -a 1.9.4 297a70e5102f76e189f4b33167c3a15d5774c820 -m "Tagging 1.9.4 Release"
git push --tags

[royhills]

Thanks for taking the time to do this.

Mostly, the two-digit releases like 1.0, 1.1, 1.2 etc. were public releases are received fairly extensive testing against various OSes, whereas the three-digit releases like 1.9.1 were internal releases that I made which were only tested on Debian Linux. But they are all worth having tags for.

Previously, I've created the tarballs with "make dist", which includes "configure" so the users don't need to have automake/autoconf. I'm not sure whether the various package maintainers will be happy to fetch the code directly from git, given that it will require the extra automake steps. But if they are, it certainly makes things easier.

I'll notify the debian maintainer first, as I know it works fine on debian given that's what I develop and test it on. As you say, there have been a few changes since the last major release.

[royhills]

I've added the relevant changes from the NEWS file to the stable releases, and uploaded the tarballs and windows zip files.

Next thing to do is to update the README.md file and wiki with installation details, as there are different Linux/Unix steps depending on whether you're building from git source (which needs autoreconf) or from a downloaded tarball (which doesn't).

[claudijd]

Ah nice, I didn't know the releases page supported such a dynamic setup. Looks really nice that you can call out the public releases versus the minor releases.