Mike Matrigali wrote:
I don't have a problem with allowing 4th digit bumps to any branch
by any committer. If someone wanted to bump this with every change
I also would not have a problem. As Kathey mentioned this would
force a query recompile for every fix which might be safer, rather
than force someone to remember it if the fix required the recompile.
Even if there is not an official apache release
it can help the discussion between developers working on their own
builds off the branch to better exactly describe the code they are
working. The svn build number included helps with this but some
tools and applications just deal with the 4 part version number more
naturally.
Should we just change the build process to make the 4th digit
the build number, ie. the svn number of the last change included
in the build? This would give an exact release id for every
change and not require manual intervention. Does this break something?
I know some process requires one of these numbers to be 0 to force
a bets.
I don't think we should have JIRA referring to any external releases
made by anyone. But it would be nice in JIRA to be able exactly
refer to a point in a branch, even if it is not released yet. This
way a bug could be logged that say is a regression to the unreleased
branch but does not affect changes before X. Currently I just add
comments saying the regression happened with change # xxxxx, but it
would be better to be able to update the jira affects version field
with something exact. For instance this could allow someone how wants to
make an official apache release to run a query and decide to make it
include changes up to X release id but not everything as there is an
outstanding issue.
What if we added a new JIRA field to supplement the "affects version"
field? The new field could be a short text box for recording specific
subversion commit-stamps. This could be blank for issues filed against
official releases but could be useful for identifying other points on
the community branches.
Regards,
-Rick
