Hi Dag,
Here's my $.02: I think that there is plenty of precedent for checking
in partial features. There is even precedent for removing unfinished
features before cutting the release branch. I suspect that your upgrade
code will be checked in long before Bernt builds the 10.4
release--that's at least 2 months out. If the Roles work is not
done--and we decide that we want to go ahead with 10.4 anyway--then I
think we can get away with the following:
1) Leave the catalog changes in. That means that a hard-upgrade will add
the new system table and its indexes even though they won't be used.
2) Disable role creation in the parser.
3) Disable the roles tests.
4) If you don't submit user documentation until the feature is complete,
then there shouldn't be any need to back out documentation changes.
That sounds like a small amount of back-out work to me and the
destabilization risk seems minimal. So I say
a) +1 to incremental development
b) Check in what you've got now and move on to the next increment.
Cheers,
-Rick
Dag H. Wanvik wrote:
In the roles work I am introducing a new catalog, SYS.SYSROLES.
I am considering impacts of committing new the code to trunk and would
appreciate some advice.
- In the event that the roles feature is not ready for 10.4, it would
need to be backed out, which could cause some turbulence in a
release end-game. Is this an acceptable risk, or should a new
feature which introduces a new catalog be on its own branch until it
is ready (with the ensuing merge pains) ?
I would prefer to stay on trunk, but realize there is a potential
downside if the feature is not ready in time..
- When committing the patch for DERBY-3137, until I include hard
upgrade code to add the new catalogue, an upgraded database will
lack the new catalog and fail whenever a role related statement or
expression is used ERROR XSAI2: The conglomerate (-1) requested does
not exist. Some tests which are sensitive to the number of catalogs
would also fail when run against an upgraded database for the same
reason.
In the spirit of incremental development, is it OK to check in the
new catalog code (hard upgrade doesn't break; it just doesn't do all
it is supposed to do yet), or should I wait until I have a patch
that handles the upgrade as well?
Thanks,
Dag
