db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Bugs and 10.1.2 release
Date Thu, 01 Sep 2005 23:52:24 GMT
Andrew McIntyre wrote:

> Funny you should ask, I'm in the middle of writing up a doc on the 
> release process from end to end. This will be a good opportunity to 
> test and review the instructions as you go along and we can make sure 
> that nothing was missed.
> So yes, I'll certainly help out with it as the process goes along.

Thanks Andrew. My thought is that you would be official release manager
and I help mostly by tracking the bugs but  performing other subtasks as
well.   Is that ok?    But yes, I can help test and review the
instructions. .

> The first thing to do would be to target the bugs you want fixed in 
> the release in JIRA. I've created a 10.1.2  release in JIRA and moved 
> all the bugs to be targeted for 10.1.2.
Thanks for making the Jira updates.   

Since this release  is kind of date driven,  would it not  be up to the
individual fixers to mark the target fixin for 10.2, then in the end
game we resolve  that with reality?    How would we work the dates
backward if we wanted a release on the website say October 26?

When should fixers plan to have their bugs fixed?
When would we call  a vote?
Could fixes still go into 10.1 during the testing/voting period?

> Speaking of versioning, this should probably be a separate mail, 
> perhaps with a vote, but I like the idea that you proposed before: 
> that a committer can bump the final version number if they are 
> committing small fixes to the branch, and that larger bug-fix-rollup 
> releases like 10.1.2 should be the level at which we are tracking 
> versions in JIRA, in STATUS, and elsewhere. If there's consensus for 
> that, I can work on writing ant targets for bumping the version 
> number and automatically dealing with the associated test diffs, etc.

I think using the fourth digit would be good.  Since we have it, we may 
as well use it instead of the build number to identify fine grained fix
versions.  It seems a little confusing though to have a bug fixed in say  and have the Jira Fixed In version be 10.1.2, but  perhaps
that's more workable than having so many versions in Jira and trying to
mark them correctly. 


View raw message