Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2
branch?
If we fix critical bugs during that time in the 10.2 branch can't
they
go into the release end of October?
They should be able to. Since we won't have had a GA release (JCP
rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require
a new
release candidate and new vote. Could even be a database format
change.
Let me work out the implications of this.
o Mustang would ship with a release candidate which the community
rejected.
o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA
status.
A couple issues come to mind:
o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier
after
producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
I think we have bumped the fourth version ("point") digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.
o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
I apologize for creating confusion here. We'd like Mustang to ship
with a fully functional Derby, which creates upgradeable databases. So
I'm assuming that we turn off the beta marker on the vetted candidate
before handing the candidate to Mustang for QA bake-in.
Re-reading your comment, I see another issue which I need to clarify.
The release candidate is not a GA implementation under the JCP as I
understand this process. The candidate does not become GA until we post
it on the Apache mirrors and announce, via the Derby website, that it is
the latest Derby release.
