db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Bumping the fourth digit
Date Wed, 11 Feb 2009 20:41:33 GMT
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.
If the 3rd number is 0, then the distribution is marked as "alpha". The 
"beta-ness" of a distribution is determined by a special beta flag in 
tools/ant/properties/release.properties. I don't think the build changes 
are very complicated for making our release ids look like 10.3.3.706492 
(to use Kathey's example). There would be some chicken-and-egg problems 
associated with generating the release notes since they are checked into 
the codeline and are compiled from issues that are marked for inclusion 
in the release. I think we could untangle these issues if we decided 
that we liked this kind of release id.
>
> 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.
>
>


Mime
View raw message