I don't believe doing a beta off the trunk implies features can't be
checked in after the snapshot is made. I don't believe it's right to
try to enforce such a restriction on the trunk.
My understanding of what Andrew describes is that you can cut a branch
later and reverse-merge the feature changes out, or go back in
revision-time and cut a branch from a point before the feature was
checked in and then merge over all subsequent bug fixes.
I understand Dan's concern about doing a beta snapshot off of the trunk
(e.g. "the trunk is for cutting-edge stuff"). But if the majority of
work happening on the trunk over the next few weeks is going to be
maintenance work and nobody is planning on going pell mell with new
features, then I think it's more manageable for us to stay on the trunk
rather than "swim with weights" as Rick puts it by cutting a branch for
our first beta snapshot and having to merge every subsequent bugfix over
to the branch.
But if committers are planning on committing a lot of new feature work
or other destabilizing changes into the trunk over the next few weeks,
we should probably cut a branch.
David
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Andrew,
Andrew McIntyre wrote:
On 8/9/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
Hi David,
I think there's a significant delta between the last snapshot and the
beta I plan to cut imminently. I would recommend that people wait for
the beta.
Are you planning do the beta out of the trunk? I don't think there's a
need to branch until there's actually potential for release. It'll
save a lot of merging.
I think this is a great idea. I will just cut the beta off the trunk.
What exactly is the plan here, people have been throwing around beta but
I don't know what that means in this context? Are you going to change
the version information so Derby reports itself as beta? Doing that on
the trunk just seems wrong, maybe it's ok, but isn't the trunk always
alpha, cutting edge, etc?
Confused,
Dan.
Here are the options so far. I've never done this before so I'm grateful
for advice from those who have already been down this road:
1) Create a branch and change the version information so that Derby
reports itself as beta.
+ It's clear that the the built code is beta.
- Bug fixes must be tested/committed to two codelines.
2) Continue working in the trunk.
+ For a week or two longer we only have to test and commit in one codeline.
- Requires that committers not check in partial features for a week or two.
- The beta candidate says that it is alpha.
3) Continue working in the trunk but mark the version as beta.
+ For a week or two longer we only have to test and commit in one codeline.
- Requires that committers not check in partial features for a week or two.
- The trunk says it is beta, which may be confusing.
4) Other options?
I would appreciate guidance from the community about which of these
options seems least onerous and/or confusing.
Thanks,
-Rick
