db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Bugs and 10.1.2 release
Date Mon, 29 Aug 2005 19:01:21 GMT
I was wondering the same thing and wanted to know if there was any
kind of published plan or content thoughts for the next "major"
release (10.2)...I understand that due to the nature of the community,
it does make sense to release a "major" numbered release when
sufficient and significant features have been checked-in - this is one
approach which probably lead to a 6-month release cycle for "major"
releases...versus 2-3 months for the minor ones...

Thanks,

--francois

On 8/29/05, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> Hi Kathey,
> 
> This sounds like a reasonable plan. By the way, what happened to the
> discussions about having a regular release schedule? Sounds like you're
> targetting October for releasing 10.1.2. Do we have a release date for
> 10.2? Here are two possibilities:
> 
> Scenario 1:
> 
> October '05:  Release 10.1.2
> January '06: Release 10.2
> 
> Scenario 2:
> 
> October '05:  Release 10.1.2
> January '06: Release 10.1.3
> April '06: Release 10.2
> 
> Cheers,
> -Rick
> 
> 
> Kathey Marsden wrote:
> 
> >We are beginning to accumulate quite a bug backlog. There is a filter
> >available on Jira  that shows the current open bug backlog, "Derby open
> >code bugs".  Currently there are 108 bugs.
> >
> >In order to avoid the mad dash at 10.2 release time and to make fixes
> >available to users, I was thinking it would be good to plan for a 10.1.2
> >release.
> >
> >Here are my thoughts  for developers...
> >
> > 1)  Pick a bug and fix it.
> >     Developers, look at the bug backlog and pick a bug
> >     you would like to fix and fix it  in the *trunk*.
> >
> > 2)  Submit your patch for the trunk.
> >     Indicate if you would like the fix to go into the 10.1 branch.
> >     (Risky code changes or behavior change best stay in the trunk).
> >
> > 3)  Merge the change to 10.1
> >     After you patch has been committed, if no one has objected
> >     to the patch going into 10.1, test your change on the 10.1 branch,
> >and submit either
> >          a) the svn command to integrate your change to 10.1
> >          b) a 10.1 patch if the merge was not automatic.
> >
> > 4) Repeat 1-3 many times.
> >
> > 5) Release.
> >    Have a vote for release in October or potentially sooner if
> >    we get a large number of fixes in the branch or there is a
> >    show stopper along the way.
> >
> >Related  items:
> >I would  send a mail to derby-user to encourage folks to start voting
> >for issues that they would like fixed. This will help us prioritize the
> >bugs we want to fix.
> >
> > It would be great if we had more folks reviewing patches.  Ideally
> >fixes will have already been through one review by another developer
> >before a committer looks at it.
> >
> >Thoughts ?
> >
> >
> >Kathey
> >
> >
> >
> >
> 
>

Mime
View raw message