0.4.0 release notes

[garlick]

Here's a stab at release notes for a 0.4.0 release:

• Scalability improvements:
  • don't store broken-down hwloc topology in the KVS (#716)
  • route rank-addressed requests via TBON (#689)
  • streamline matchtag handling (#687)
  • keep active jobs in a separate KVS namespace from "archived" jobs (#609)
• New features:
  • implement PMI-1 simple server in wrexecd (#706)
  • add skeletal PMI-2 library (based on PMI-1) (#747)
  • make libflux-optparse.so available externally (#702)
  • asynchronous KVS fence and rewritten fence path in KVS module (#707, #729)
  • flux-cron, a cron/at-like service (#626)
  • flux-proxy and ssh:// connector (#645)
• Other changes:
  • Use RFC 5424 log format for internal logging, not ad hoc JSON (#691)
  • Add wreck lua.d MPI personalities (#669, #743, #747)
  • Improved command line for launching flux from slurm/flux (#658)
  • Assorted code cleanup.
  • Automatic github release upload on tags (#744)
• Testing:
  • Print backtraces for any core files generated in travis-ci (#703)
  • Add cppcheck target to travis-ci (#701)
  • configure --enable-sanitizer for AddressSanitizer, ThreadSanitizer (#694)
  • caliper based profiling (#741)
  • improved test coverage
• Deprecations
  • Sophia content backing store module (#727)
  • mrpc KVS based muti-RPC interface (#689)
  • ZPL config file (#674)
  • Ring overlay network (#689)

[grondo]

Thanks!

Do any of the other items on 0.4.0 milestone still belong there or should we punt them to 0.5.0?

Should we add @trws's Caliper tracing support to the milestone for 0.4.0? I was working on getting Caliper building in travis so we can test it, but the testing could be added as a future commit. For now I could publish my fork of @trws's branch and we could work on that as a new PR?

[garlick]

I was just (slowly) visiting each of the milestone items and was going to comment on each. Stand by.

I think we ought to get caliper support in. Your plan to create a new PR makes sense to me.

This above was just intended as a start and was put together pretty quickly. I always seem to suspect I have more to say about my own work than that of others in these things so please comment if I've left gaps or thin areas.

[grondo]

It looked pretty complete to me, I usually just list the merge commits to double check

git log --merges 0.3.0..HEAD

At one point we had talked about having special tagged commit messages (required for PRs?) that could emit a line of Release Notes. Something like that will be required to automate the process.

[garlick]

Just updated the release notes above with

• pmi2 library
• caliper support
• automatic github release upload on tag

[grondo]

Great! I think the process for a release will now be two steps:

• Create PR NEWS.md: Update for release v0.4.0, with heading like

  flux-core version 0.4.0 - 2016-08-11
  ------------------------------------

• After PR is merged, tag v0.4.0 (I realize we aren't using the "v" prefix, that seems to be common and allows version tags to be listed quite easily git tag -l | grep ^v -- any reason not to switch to it? I'm actually not feeling strongly either way.
• Push the tag, which should cause the release tarball and link to NEWS.md file to be added to the GitHub release. If it works the first time I'll actually be surprised.

[garlick]

I think 0.4.0 is ready once your coverage PR is merged. I'll get a PR going for NEWS.md.

[garlick]

On the "v' prefix to tags: I also don't mind. Should I add a patch to the NEWS PR to snip "v" off the front of the result of git describe so that it won't appear in PACKAGE_VERSION, the dist tarball, etc?

[garlick]

We've tagged, so closing this.