FWD

We need to be able to determine the P2J version we're using on a given P2J server deployment. There are several ways we could achieve this. One simple one would be to include this in the manifest for the p2j.jar. I think the standard way of doing this would be to set the following in the manifest:

Implementation-Version: <p2j revno>

Further details can be found here:
https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html

Knowing what ant it like, I imagine the easiest solution to passing the revno in might be to use an environment variable rather than shelling out to access it. That would be fine for us.

Feedback on this would be appreciated - e.g. milestone alignment, acceptance / rejection, suggested approach.

This is a duplicate of #28 which is planned for work in the deployment improvements milestone. Since it doesn't affect functional or performance objectives it is not a priority. But we have and do plan to work it.

We will have a multi-part version string which will likely include:

• major version
• minor version
• release
• repo (e.g. p2j for the main trunk and branches or optionally this may be a custom build line for a specific customer)
• branch name
• branch revision

The first 3 of these (major.minor.release) are really to map our understanding of the version to something to which a customer can relate. This is something that we might check in to bzr and won't change often. When we change it, it will be deliberate and will be done to mark future releases with that level. The rest very clearly map a build to a specific lineage of code at GCD. These values are less static, but can possibly be derived from bzr itself.

I would expect the resulting version string to be something like 2.5.2_p2j_trunk_11020.

The manifest is certainly an option. It would need to be edited at build time as you note, since we would not want to commit such changes into the branch.

The problem is getting access to the various details needed without making the build process fragile. If I had a trivial answer for this it would be done already.

I agree that this isn't a very near-term concern.

I'm keen on getting something simple in place before full manual testing. The reason for this is that, whilst we will start the manual testing exercise with a number of systems all on the same P2J revision, I imagine that this may change as we pick up new revisions to test bug fixes. I'm assuming you'd like to know the P2J revision that was used when receiving a bug report. It will be less effort to implement something simple to allow basic inspection of a jar to reveal the revision rather than keeping track some other way.

If this isn't something that you plan to do before full manual testing then I'll implement something. I'm not keen for our build scripts to diverge so I'll either come up with a way of doing this that doesn't involve changing your build scripts, or request that you accept my changes.

FWD revision 11138 provides version support. Please see #28 for details.