On 8/9/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Is there any impact to having a milestone event like beta 10.2 not
recorded in our svn history?
Yes, and its a matter of confidence as to what a 'beta 10.2' that is
broadcasted far-and-wide actually represents. The beta code, built
through
Kathey Marsden wrote:
Andrew McIntyre wrote:
On 8/9/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Is there any impact to having a milestone event like beta 10.2 not
recorded in our svn history?
If the beta reports as being at a revision that is modified
from what's in svn, then that's a
On 8/10/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Andrew McIntyre wrote:
I think there's some confusion over the fact that in svn, copy ==
branch (== tag).
Yes. I was confused by that. So the proposal is just for two branches.
One now for beta and then another one later for th 10.2
Andrew McIntyre wrote:
So, the first one is more of what traditionally would be called a tag,
except that it has one extra change in it than what is in the trunk -
the change to make it report as beta. The second one is what more
traditionally is called a branch.
In svn, everything is a copy,
Thanks to everyone for thinking through the issues here. This has been
very helpful. I don't understand the practical advantages of a copy
versus a branch, particularly since I will have to create a branch
eventually. I could use some more education here. What would be the
objections to the
If we can assume that nobody will be checking in fixes to the beta
branch, and that therefore the mega-merge is a one-way operation with
no manual conflicts to deal with, then I think this approach makes sense.
Thanks,
David
Rick Hillegas wrote:
Thanks to everyone for thinking through the
On 8/10/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Thanks to everyone for thinking through the issues here. This has been
very helpful. I don't understand the practical advantages of a copy
versus a branch, particularly since I will have to create a branch
eventually. I could use some more
Rick Hillegas wrote:
Thanks to everyone for thinking through the issues here. This has been
very helpful. I don't understand the practical advantages of a copy
versus a branch, particularly since I will have to create a branch
eventually. I could use some more education here. What would be
This is the procedure I was expecting (except expected to have to
merge myself it i wanted something in branch), sounds good to me.
I was going to be ok with holding up the branch for the code
rototil if necessary, that seemed like a reasonable delay for
solving an apache mandate. Having
a real
I was going to blog about this, but I realized I didn't know if 10.2 was
officially beta or not. I guess that happens after we branch and Rick
flips the beta bit?
If I were to blog about getting 10.2 tested today (before we're
officially beta), what do I say? Should they get the latest
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.
Regards,
-Rick
David Van Couvering wrote:
I was going to blog about this, but I realized I didn't know if 10.2
was officially
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
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
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
On 8/9/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
As long as it's understood the trunk remains open for all new stuff
including new (partial) features. We could delay a branch, one can
always go back-in-time to create a branch from an existing svn
revision point, right?
Correct. If a
Is anyone planning on submitting a partial feature in the next two
weeks? If so, this will affect my decision about whether to create a branch.
Regards,
-Rick
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
On 8/9/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Hi David,
I think
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
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
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
Rick Hillegas wrote:
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.
good.
- Bug
On 8/9/06, Kathey Marsden [EMAIL PROTECTED] wrote:
I say this is not true. We make the branch and just make that one beta
flag flip.
Everyone gets their builds setup and running but we keep working on the
trunk.
Nobody bothers with merging fixes to the branch.
Then at whatever point we feel
You make the step someone does one biggish merge with the range for all
that has gone into the trunk so far sound deceptively simple. Is it
really that easy to do a biggish merge with any level of confidence?
I know it would make *me* nervous (e.g. I am not volunteering for that job).
What's
Interesting idea. I feel like I'm really missing something. If no
other changes go into the svn copy, why are we making the copy?
David
Andrew McIntyre wrote:
On 8/9/06, Kathey Marsden [EMAIL PROTECTED] wrote:
I say this is not true. We make the branch and just make that one beta
flag
David Van Couvering wrote:
Interesting idea. I feel like I'm really missing something. If no
other changes go into the svn copy, why are we making the copy?
I guess the goal is to flip the beta flag in the copy.
Trunk would still be alpha as usual.
This would be approach 4) Other options,
Not a partial feature, but I'm working on DERBY-1517 and I will need to
do a lot of testing - It is a fix that needs to get in so that DRDA
Strong Password Substitute Authentication (USRSSBPWD) security
mechanism can be re-enabled as a second best default when EUSRIDPWD
cannot be used (i.e. JVM
On 8/9/06, David Van Couvering [EMAIL PROTECTED] wrote:
Interesting idea. I feel like I'm really missing something. If no
other changes go into the svn copy, why are we making the copy?
What Kristian said. Basically, there needs to be a copy somewhere in
svn where we can mark it as beta,
David Van Couvering wrote:
You make the step someone does one biggish merge with the range for
all that has gone into the trunk so far sound deceptively simple. Is
it really that easy to do a biggish merge with any level of confidence?
I think the merge command would be something like:
Andrew McIntyre wrote:
There's another option, too, that I just thought of. svn copy the
trunk into tags/10.2.1.0_beta. Flip the beta flag, roll the beta
distributions. No other changes go into this copy of the trunk.
Is there any impact to having a milestone event like beta 10.2 not
Rick Hillegas wrote:
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
On 8/7/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How can we make a big splash with the Beta Announcement and follow-up to
get users pounding on 10.2 to make sure this is a quality release?
I am interested in ideas from the community.
Well, apparently posting to derby-user is not enough. So,
Andrew McIntyre wrote:
On 8/7/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How can we make a big splash with the Beta Announcement and follow-up to
get users pounding on 10.2 to make sure this is a quality release?
I am interested in ideas from the community.
My small contribution: I have a
On 8/8/06, Bernt M. Johnsen [EMAIL PROTECTED] wrote:
Andrew McIntyre wrote:
On 8/7/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How can we make a big splash with the Beta Announcement and follow-up to
get users pounding on 10.2 to make sure this is a quality release?
I am interested in ideas
Andrew McIntyre wrote:
On 8/8/06, Bernt M. Johnsen [EMAIL PROTECTED] wrote:
Andrew McIntyre wrote:
On 8/7/06, Kathey Marsden [EMAIL PROTECTED] wrote:
How can we make a big splash with the Beta Announcement and
follow-up to
get users pounding on 10.2 to make sure this is a quality
after a year of development
Although it's no help for the current situation, I think that one of
the issues here is that our release cycle for this release is too long,
and we've strayed from the Release Early, Release Often advice
Bryan Pendleton wrote:
after a year of development
Although it's no help for the current situation, I think that one of
the issues here is that our release cycle for this release is too long,
and we've strayed from the Release Early, Release Often advice
On 8/8/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
Glad you mentioned it, btw. Everybody on this list that has a blog
should mention the beta there.
Wouldn't that require that we actully have a beta period? Haven't seen
that in the 10.2 schedule.
Well, it is in fact fully up to our
Andrew McIntyre wrote:
On 8/8/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
Glad you mentioned it, btw. Everybody on this list that has a blog
should mention the beta there.
Wouldn't that require that we actully have a beta period? Haven't seen
that in the 10.2 schedule.
Well, it
Rick Hillegas wrote:
I hope to rely heavily on the community's advice here. I'm a bit
unclear on the distinction between a beta and a release. Is it
basically a matter of whether the beta bit is turned on, preventing
the candidate from building upgradable databases? Or does does the
Dear Development Community,
I find myself very concerned about the small amount of feedback we have
gotten so far from the user community on 10.2. We have heard no feedback
really positive or negative on the major new features, like
grant/revoke, SUR, online-backup and JDBC 4.0. We've
39 matches
Mail list logo
