Page History

...

Note that it really doesn't matter what branching policy is used on the svn tree, e.g. release candidates could be made from a feature branch, from trunk, or from a release branch and because the artifacts capture the precise point in svn history they were made from, we can always retroactively branch and tag from that point should the release candidate prove worthy.

Producing Binary Artifacts

For the C build we simply don't do this. For the Java build there are a bunch of steps that I don't really understand but have learned to monkey through:

1. untar and cd into the proton source tarball
2. run "mvn -P apache-release deploy" (note that for this step to succeed you need to do mysterious and annoying things like putting your apache password in cleartext inside your .m2/settings.xml file)
3. go to https://repository.apache.org/index.html, login and click on one of the Staging links (Repositories I think) and find the thing that maven just uploaded (it should say open or opened or something like that and have a recent date)
4. poke at the clumsy ui until you figure out how to "close" it, and then record the URL it gives you for the repo

Testing the tarball

The challenge here is the variety of different environmental variables to factor in. For proton-c itself we have different architectures to contend with as well as different cmake versions and different versions of the few key libraries we depend on (e.g. openssl). On top of this, for each binding we have not only the language version, but also the version of swig available, and even if those are the same, the configuration of the interpreter may vary depending on which OS we're building on.

All of this of course makes a myriad of combinations, and we don't really have much in the way of CI coverage to help us yet, and even if we did, many of the factors are actually related to install testing and won't actually show up unless you do a full make install as root and try to access the proton library from each binding as an end user would. While not impossible to automate this level of testing is of course much more difficult to automate, so for the short to medium term at least, testing the C artifacts requires a reasonable amount of manual checking.

The full check for any given configuration/environment would involve installing all the dependencies required for any optional pieces (omitting any that are unavailable of course) doing a full build and a make install (as root), running the python test suite (this checks both the C library and the python binding), and then for each of the non-python bindings doing at least a minimal check that the binding works and running any binding tests available.

...

Testing the Source Artifacts

Testing Checklist

The following checklist can be used to sanity check the output of the steps above. Ideally we will automate some or all of these checks.

...

.
|-- CMakeLists.txt
|-- LICENSE
|-- README
|-- SVN_INFO           ** check contents **
|-- TODO
|-- bin
|   `-- release.sh
|-- config.sh
|-- pom.xml            ** check version number **
|-- proton-c
|   |-- CMakeLists.txt
|   |-- ...
|-- proton-j
|   |-- ...
`-- tests
    |-- ...

Build and install

Follow the instructions in README to install proton, preferably using a temporary install prefix, e.g.:

...

TODO Java installation is not yet implemented as at Jan 2013 so the best you can do is to check that proton-api, proton-j-impl and proton-jni jars have been built under ./build/.

Test

Follow the instructions in README to run the tests.

Testing Notes

The challenge here is the variety of different environmental variables to factor in. For proton-c itself we have different architectures to contend with as well as different cmake versions and different versions of the few key libraries we depend on (e.g. openssl). On top of this, for each binding we have not only the language version, but also the version of swig available, and even if those are the same, the configuration of the interpreter may vary depending on which OS we're building on.

All of this of course makes a myriad of combinations, and we don't really have much in the way of CI coverage to help us yet, and even if we did, many of the factors are actually related to install testing and won't actually show up unless you do a full make install as root and try to access the proton library from each binding as an end user would. While not impossible to automate this level of testing is of course much more difficult to automate, so for the short to medium term at least, testing the C artifacts requires a reasonable amount of manual checking.

The full check for any given configuration/environment would involve installing all the dependencies required for any optional pieces (omitting any that are unavailable of course) doing a full build and a make install (as root), running the python test suite (this checks both the C library and the python binding), and then for each of the non-python bindings doing at least a minimal check that the binding works and running any binding tests available.

During this process of course some steps may fail, e.g. the specific version of a given language may not build, or the openssl library might not be recent enough, and some level of that is ok of course as long as we document what did/did not work for the given configuration/environment.

Producing Binary Artifacts

For the C implementation we simply don't do this. For the Java implementation there are a bunch of steps that I don't really understand but have learned to monkey through:

1. untar and cd into the proton source tarball
2. run "mvn -P apache-release deploy" (note that for this step to succeed you need to do mysterious and annoying things like putting your apache password in cleartext inside your .m2/settings.xml file)
3. go to https://repository.apache.org/index.html, login and click on one of the Staging links (Repositories I think) and find the thing that maven just uploaded (it should say open or opened or something like that and have a recent date)
4. poke at the clumsy ui until you figure out how to "close" it, and then record the URL it gives you for the repo

Notes

The only stage here that really needs to be done by one person is producing the release tarballs. I expect as we wish to offer more binary artifacts and producing them becomes more complex (e.g. requiring a windows box) we will need to distribute the responsibility for producing binaries, e.g. have a java developer produce the java binaries, have a windows developer produce windows binaries, have a ruby developer produces gems, and so forth.