Answering some other concerns:

re: We might care considering enhancing the build process such that is stores
the commit ID from which the release is carved into some file.

I think the release:prepare / release:perform does this.. 

   The "prepare" creates the non-snapshot version of the source code,
    commits it and tags it with the non-snapshot version number

   The "perform" checks out that specific tag and builds from that.
   So there ought to be some guarantee of a match between the tag and what gets
built.

re: Why do we have two releases, i.e. one for UIMAJ and one for the update site?

   I think this was done as a matter of convenience, and
   the uimaj-eclipse-update-site project build isn't really considered to be a
release,
   because it is just the Eclipse feature/plugin packaging of things that were
built as part
   of the normal release process, and the associated "source code" is just a
bunch of
   configuration specs on how to put together the update site packaging.

   For the uimaj root project, we do a release:prepare, release:perform, but
   for the uimaj-eclipse-update-site project we only do a release:prepare . 
   For the uimaj-eclipse-update-site project, this serves to
   build the eclipse plugin packagings, and also increments the version number
for that one project.

   I'm sure this could be improved, but, as it's working fine at the moment (I
think), there's
   little incentive to work at improving it.

-Marshall

Reply via email to