You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2008/10/21 21:44:52 UTC
Branching 1.6 on Nov. 5
Hi all.
As has been discussed on IRC, dev@, and at the summit last week, we're shooting
for a 1.6.0 release toward the end of December, approximately 6 months after
1.5.0. Given that goal, and our typical release cycle, that would mean
branching near the end of October/beginning of November. So I'm pegging the
branch date at Nov. 5, 1700 UTC.
I'll follow this up with my standard disclaimer: this date isn't set in stone
(more like quick drying concrete). If there are serious and valid concerns, we
can push the date back a week or so, but I'm hesitant to go any farther than that.
In the meantime, please try and be a little conservative about what makes it
into trunk, so that it's pretty stable when we branch.
Thanks,
-Hyrum
PS - For reference, some previous threads on the subject are here:
http://svn.haxx.se/dev/archive-2008-09/0598.shtml
http://svn.haxx.se/dev/archive-2008-02/0847.shtml
Re: Branching 1.6 on Nov. 5
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Hyrum K. Wright wrote:
> +1. Some flexibility and accommodation is fine, but we *must not* repeat
> Subversion 1.5 again.
Absolutely.
I see you already put the sparse-dirs deselection stuff into TODO-1.6,
Hyrum -- thanks.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching 1.6 on Nov. 5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> I'm still open to pushing the branch back a week or so, but I think anything
> beyond that would impair our ability to publish a quality release before the end
> of December.
+1. Some flexibility and accommodation is fine, but we *must not* repeat
Subversion 1.5 again.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Branching 1.6 on Nov. 5
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K. Wright wrote:
> I've been hearing from a couple of sources that Nov. 5 may be a bit premature.
> To help us gage what is left to be done before we branch, r33897 created the
> TODO-1.6 file in the trunk. Please add whatever tasks you have to this file, so
> we can better determine if Nov. 5 is appropriate to branch.
Thanks. I'll add something about tree-conflicts.
> I'm still open to pushing the branch back a week or so, but I think anything
> beyond that would impair our ability to publish a quality release before the end
> of December.
Steve and Stefan and Neels and I are hurrying to get some tree-conflicts
stuff sorted out, but I don't have an accurate enough estimate to be
able to say whether there wlil be a major benefit to a having few extra
days.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching 1.6 on Nov. 5
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Karl Fogel wrote:
> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>> As has been discussed on IRC, dev@, and at the summit last week, we're
>> shooting for a 1.6.0 release toward the end of December, approximately
>> 6 months after 1.5.0. Given that goal, and our typical release cycle,
>> that would mean branching near the end of October/beginning of
>> November. So I'm pegging the branch date at Nov. 5, 1700 UTC.
>>
>> I'll follow this up with my standard disclaimer: this date isn't set
>> in stone (more like quick drying concrete). If there are serious and
>> valid concerns, we can push the date back a week or so, but I'm
>> hesitant to go any farther than that.
>>
>> In the meantime, please try and be a little conservative about what
>> makes it into trunk, so that it's pretty stable when we branch.
>
> The only flag I'd raise is that I'd like to get Guo Rui's
> sparse-directories deselection changes merged:
>
> http://svn.collab.net/repos/svn/branches/issue-2843-dev
>
> I've started bringing the branch up-to-date in r33560 and r33561, but
> haven't finished yet. I won't be able to resume work on that until
> Nov. 1st. While I think I will be able to get it all merged by the 6th,
> it may be somewhat destabilizing.
>
> My proposal is that we just play it by ear. I'll complete the merge (on
> the branch), play around with it, post results, and then we decide if we
> want it in 1.6 or 1.7. As long as it either gets into 1.6, or gets into
> trunk immediately following 1.6 (so it's in 1.7), that'd be fine, though
> of course 1.6 would be my preference.
I've been hearing from a couple of sources that Nov. 5 may be a bit premature.
To help us gage what is left to be done before we branch, r33897 created the
TODO-1.6 file in the trunk. Please add whatever tasks you have to this file, so
we can better determine if Nov. 5 is appropriate to branch.
I'm still open to pushing the branch back a week or so, but I think anything
beyond that would impair our ability to publish a quality release before the end
of December.
-Hyrum
Re: Branching 1.6 on Nov. 5
Posted by Karl Fogel <kf...@red-bean.com>.
"Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
> As has been discussed on IRC, dev@, and at the summit last week, we're
> shooting for a 1.6.0 release toward the end of December, approximately
> 6 months after 1.5.0. Given that goal, and our typical release cycle,
> that would mean branching near the end of October/beginning of
> November. So I'm pegging the branch date at Nov. 5, 1700 UTC.
>
> I'll follow this up with my standard disclaimer: this date isn't set
> in stone (more like quick drying concrete). If there are serious and
> valid concerns, we can push the date back a week or so, but I'm
> hesitant to go any farther than that.
>
> In the meantime, please try and be a little conservative about what
> makes it into trunk, so that it's pretty stable when we branch.
The only flag I'd raise is that I'd like to get Guo Rui's
sparse-directories deselection changes merged:
http://svn.collab.net/repos/svn/branches/issue-2843-dev
I've started bringing the branch up-to-date in r33560 and r33561, but
haven't finished yet. I won't be able to resume work on that until
Nov. 1st. While I think I will be able to get it all merged by the 6th,
it may be somewhat destabilizing.
My proposal is that we just play it by ear. I'll complete the merge (on
the branch), play around with it, post results, and then we decide if we
want it in 1.6 or 1.7. As long as it either gets into 1.6, or gets into
trunk immediately following 1.6 (so it's in 1.7), that'd be fine, though
of course 1.6 would be my preference.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching 1.6 on Nov. 5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Sperling wrote:
> Still: Mike, Ben, I'd happliy review and/or extend any
> tree-conflict-related material for the svnbook.
> Don't hesitate forwarding stuff to me.
Noted (and "thanks"). I dunno if there will be a 1.6 version of the book,
though, unless others step up to donate content. I'm pretty sure Ben and
Fitz are as burned out on technical writing as I am after our recent drive
to finish a print-ready 1.5 book.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Branching 1.6 on Nov. 5
Posted by Stefan Sperling <st...@elego.de>.
[Ben & Mike in Cc: Skip to the very end of this mail.]
On Wed, Oct 22, 2008 at 01:46:17AM +0200, Neels J. Hofmeyr wrote:
>
>
> Hyrum K. Wright wrote:
> > Hi all.
> >
> > As has been discussed on IRC, dev@, and at the summit last week, we're shooting
> > for a 1.6.0 release toward the end of December, approximately 6 months after
> > 1.5.0. Given that goal, and our typical release cycle, that would mean
> > branching near the end of October/beginning of November. So I'm pegging the
> > branch date at Nov. 5, 1700 UTC.
> >
> > I'll follow this up with my standard disclaimer: this date isn't set in stone
> > (more like quick drying concrete). If there are serious and valid concerns, we
> > can push the date back a week or so, but I'm hesitant to go any farther than that.
> >
> > In the meantime, please try and be a little conservative about what makes it
> > into trunk, so that it's pretty stable when we branch.
>
> Yes, I have a question about that. I tried to use diff to tell
> tree-conflicts detection whether two dirs are the same. Thus I found diff
> doesn't support most of the cases we need for tree-conflicts.
>
> So I span off into trying to enhance diff --summarize, finding out that even
> plain diff for a "supported" case is very much broken.
>
> To make a long story short, in order to fix diff in a sane way and to then
> be able to detect tree-conflicts properly, I would need to extend the
> (public) diff callbacks API, as in changing callbacks signatures, with minor
> repercussions through all code that uses the diff callbacks (e.g. merge).
>
> So there's two sides:
>
> a) It would be nice to have the new API change in 1.6; 1.6 already changes
> the same structure in a simpler way (svn_wc_diff_callbacks2_t ->
> svn_wc_diff_callbacks3_t), and we would avoid having to change it to
> svn_wc_diff_callbacks4_t right in the next release.
>
> b) I would probably have to hurry to get the stuff working.
>
> What do you say, "try and we'll see if it makes it in", or is it a
> resounding "nah... forget it"?
diffcallbacks3 only add dir_open and dir_close callbacks to the public
API. So in any case, the public API as-is (give or take open_dir and
close_dir) would have to be in any 1.x release.
So I'd say:
Forget about directories for now, fix up the UI in trunk before the
branch (really!), and plan to add support for directories in 1.7.
If necessarry, remove any tree conflict detection for directories from
trunk before 1.6 is branched -- we don't want it in a release if it's
only half-baked.
Tough, but if things go as planned 1.7 will be out June next year,
which is not that far away.
And tree conflicts on files will already help people a lot -- or make
them complain, I'm exited to see what users will complain about when
they first run into tree conflicts -- we'd better polish the UI before
release, and make sure the book explains tree conflicts well enough
for people who have never even thought about this problem to be able
to deal with the situation in a meaningful way.
I'm afraid I myself won't have much time to contribute any meaningful
tree-conflicts work though, finally gotta flesh out my Master's project
proposal, deadline for that is also around 5th of November :/
Still: Mike, Ben, I'd happliy review and/or extend any
tree-conflict-related material for the svnbook.
Don't hesitate forwarding stuff to me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching 1.6 on Nov. 5
Posted by Neels J Hofmeyr <ne...@elego.de>.
Hyrum K. Wright wrote:
> Neels J. Hofmeyr wrote:
>> What do you say, "try and we'll see if it makes it in", or is it a
>> resounding "nah... forget it"?
>
> I would say do what you can and we'll see if it make it in. The Nov. 5 date
> does *not* mean perfect code by the time we branch. It *does* mean that the
> feature is reasonably complete, and can be stabilized over the course of the
> next few weeks.
Cool! I should be able to see some time next week whether it makes sense to
include the API changes. A couple weeks sounds to me like ample time to
straighten it out. ... I guess ;)
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Branching 1.6 on Nov. 5
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Neels J. Hofmeyr wrote:
>
> Hyrum K. Wright wrote:
>> Hi all.
>>
>> As has been discussed on IRC, dev@, and at the summit last week, we're shooting
>> for a 1.6.0 release toward the end of December, approximately 6 months after
>> 1.5.0. Given that goal, and our typical release cycle, that would mean
>> branching near the end of October/beginning of November. So I'm pegging the
>> branch date at Nov. 5, 1700 UTC.
>>
>> I'll follow this up with my standard disclaimer: this date isn't set in stone
>> (more like quick drying concrete). If there are serious and valid concerns, we
>> can push the date back a week or so, but I'm hesitant to go any farther than that.
>>
>> In the meantime, please try and be a little conservative about what makes it
>> into trunk, so that it's pretty stable when we branch.
>
> Yes, I have a question about that. I tried to use diff to tell
> tree-conflicts detection whether two dirs are the same. Thus I found diff
> doesn't support most of the cases we need for tree-conflicts.
>
> So I span off into trying to enhance diff --summarize, finding out that even
> plain diff for a "supported" case is very much broken.
>
> To make a long story short, in order to fix diff in a sane way and to then
> be able to detect tree-conflicts properly, I would need to extend the
> (public) diff callbacks API, as in changing callbacks signatures, with minor
> repercussions through all code that uses the diff callbacks (e.g. merge).
>
> So there's two sides:
>
> a) It would be nice to have the new API change in 1.6; 1.6 already changes
> the same structure in a simpler way (svn_wc_diff_callbacks2_t ->
> svn_wc_diff_callbacks3_t), and we would avoid having to change it to
> svn_wc_diff_callbacks4_t right in the next release.
>
> b) I would probably have to hurry to get the stuff working.
>
> What do you say, "try and we'll see if it makes it in", or is it a
> resounding "nah... forget it"?
I would say do what you can and we'll see if it make it in. The Nov. 5 date
does *not* mean perfect code by the time we branch. It *does* mean that the
feature is reasonably complete, and can be stabilized over the course of the
next few weeks.
In this case, if you've got a pretty good feel for the API, I'd go ahead and get
that in, with a big disclaimer saying that parts of it may be unimplemented at
this time (and perhaps a runtime check as well). Much like wc-ng, some code is
better than no code in a lot of instances, and big features can be released
incrementally.
-Hyrum
Re: Branching 1.6 on Nov. 5
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Hyrum K. Wright wrote:
> Hi all.
>
> As has been discussed on IRC, dev@, and at the summit last week, we're shooting
> for a 1.6.0 release toward the end of December, approximately 6 months after
> 1.5.0. Given that goal, and our typical release cycle, that would mean
> branching near the end of October/beginning of November. So I'm pegging the
> branch date at Nov. 5, 1700 UTC.
>
> I'll follow this up with my standard disclaimer: this date isn't set in stone
> (more like quick drying concrete). If there are serious and valid concerns, we
> can push the date back a week or so, but I'm hesitant to go any farther than that.
>
> In the meantime, please try and be a little conservative about what makes it
> into trunk, so that it's pretty stable when we branch.
Yes, I have a question about that. I tried to use diff to tell
tree-conflicts detection whether two dirs are the same. Thus I found diff
doesn't support most of the cases we need for tree-conflicts.
So I span off into trying to enhance diff --summarize, finding out that even
plain diff for a "supported" case is very much broken.
To make a long story short, in order to fix diff in a sane way and to then
be able to detect tree-conflicts properly, I would need to extend the
(public) diff callbacks API, as in changing callbacks signatures, with minor
repercussions through all code that uses the diff callbacks (e.g. merge).
So there's two sides:
a) It would be nice to have the new API change in 1.6; 1.6 already changes
the same structure in a simpler way (svn_wc_diff_callbacks2_t ->
svn_wc_diff_callbacks3_t), and we would avoid having to change it to
svn_wc_diff_callbacks4_t right in the next release.
b) I would probably have to hurry to get the stuff working.
What do you say, "try and we'll see if it makes it in", or is it a
resounding "nah... forget it"?
Thanks
~Neels
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194