Dennis Kubes wrote:
Yes. This seems to have fixed the problem. All, do we want to create a JIRA and commit this for the 0.9 release?
It should definitely go into the release, and we need a patch for the trunk/ .
Actually, I'm somewhat surprised that we have tags/release-0.9 but we don't yet have branches/branch-0.9 ...
I think I'm confused, or the release procedure is confused. My understanding so far was that we first create a branch-0.9, we test the build from that branch and if it passes all tests and the wait period is over, then we copy it to tags/release-0.9 and proclaim a release - which is really a read-only branch, i.e. we don't ever commit any patches to it ... If that were the case, then we still wouldn't have the release-0.9 tag, we could have applied the patch in branch-0.9, plus possibly other patches, and then finally tag this tree as tags/release-0.9.
As it is now we are in an awkward situation that we have to patch tags/release-0.9 ..
One solution would be now to delete this tag, apply the patch to trunk, create branches/branch-0.9, and continue applying any other patches that may come up during this testing period - and when we are finally happy with the codebase then take a snapshot into tags/release-0.9, and keep it read-only.
Another solution is to bend the rules and apply the patch to trunk/ and then merge from the trunk to tags/release-0.9 .
What do you think? -- Best regards, Andrzej Bialecki <>< ___. ___ ___ ___ _ _ __________________________________ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
