You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by kf...@collab.net on 2003/10/03 04:50:18 UTC
0.32, the "1.0" milestone, and the 1.0 release.
A lot of folks have been asking, "What's up with the issues marked for
the '1.0' milestone? Are they after Beta, or before Beta, or what?"
Okay, actually no one's been asking that. But I wanted start with a
leading question, so I could pretend to answer it...
The "1.0" milestone has been a dumping ground for issues that are
nice-to-haves for a 1.0 release, but not truly required. I won't talk
about particular issues here; anyone looking over the 25 or so "1.0"
bugs can come to their own conclusions about which ones are important
to fix before 1.0 and which aren't. And probably not come to exactly
the same conclusion as someone else would, either :-).
Over the next day, you'll see me moving many of them to a new "1.1"
milestone, our first gradation in the hitherto-monolithic "Post-1.0"
category. The rest will get moved to 0.32 or into the general
Post-1.0 pool. None will be left in 1.0, because the only purpose of
that milestone was as a holding area until we got to this point.
I hope people are generally okay with this. I certainly don't expect
everyone to agree with every decision, but do ask that you wait until
you have an overview of all the shifts before objecting to a
particular assignation. Some serious triage is necessary, or we'll be
here all day, know what I mean? :-)
As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
are officially "in Beta". At that point, we will make a release
branch (called "stabilize-1.0" or something), which will be for
bugfixes only. There will be cross-pollination between trunk and the
1.0 stabilization branch, but risky new features will stay confined to
trunk. When the branch is ready, we release 1.0, and have a party.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 05-10-2003 14:51, C. Michael Pilato wrote:
> > the C++ binding for SVN that RapidSVN(?) has is a better approach?
>
>Hmm... that's certainly worth exploring. It unfortunately means we'd
>have to maintain the C++ wrapper, the SWIG bindings of that wrapper,
>and then (probably) some addition language-specific cleanup code atop
>that. But if the C++ API coverage is superb, maybe that's not such a
>terrible thing.
I've had a quick look and like what I see.
They are patching to catch up with the API changes in 0.30.0 from
their last base line on 0.28.0. Then I'll try SWIGing their classes,
or even write a custom python extension to call their classes.
I think when 1.1 comes around it would be far better to have an
iterator version of svn_client_status rather then the callback
implementation you have.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 05-10-2003 14:51, C. Michael Pilato wrote:
> > the C++ binding for SVN that RapidSVN(?) has is a better approach?
>
>Hmm... that's certainly worth exploring. It unfortunately means we'd
>have to maintain the C++ wrapper, the SWIG bindings of that wrapper,
>and then (probably) some addition language-specific cleanup code atop
>that. But if the C++ API coverage is superb, maybe that's not such a
>terrible thing.
I've had a quick look and like what I see.
They are patching to catch up with the API changes in 0.30.0 from
their last base line on 0.28.0. Then I'll try SWIGing their classes,
or even write a custom python extension to call their classes.
I think when 1.1 comes around it would be far better to have an
iterator version of svn_client_status rather then the callback
implementation you have.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> >While I think the scripting language is important, I disagree on your
> >assertion that it needs to be perfected for 1.0. In my mind,
>
> I never asserted that. I asked for confirmation. You have confirmed that
> 1.1 is what I will need to wait for. I'll help how I can towards 1.1 for
> the bindings.
Fair enough. Thank you for your grace.
> wxPython is very good. We build all our GUI tools using it at work.
>
> There is very little in the extra layer. 99% of the .py is generated
> out of SWIG (that begs the question of what they do in the .i files).
> They do the prefix striping.
>
> wxPython has a simpler job as wxWndows is OO so they have the object
> model. The design work for SVN is in creating that object model and
> implementing it out of the C binding. Once there is an object model it
> will be easy enough to implement in all the languages. Maybe SWIGing
> the C++ binding for SVN that RapidSVN(?) has is a better approach?
Hmm... that's certainly worth exploring. It unfortunately means we'd
have to maintain the C++ wrapper, the SWIG bindings of that wrapper,
and then (probably) some addition language-specific cleanup code atop
that. But if the C++ API coverage is superb, maybe that's not such a
terrible thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> >While I think the scripting language is important, I disagree on your
> >assertion that it needs to be perfected for 1.0. In my mind,
>
> I never asserted that. I asked for confirmation. You have confirmed that
> 1.1 is what I will need to wait for. I'll help how I can towards 1.1 for
> the bindings.
Fair enough. Thank you for your grace.
> wxPython is very good. We build all our GUI tools using it at work.
>
> There is very little in the extra layer. 99% of the .py is generated
> out of SWIG (that begs the question of what they do in the .i files).
> They do the prefix striping.
>
> wxPython has a simpler job as wxWndows is OO so they have the object
> model. The design work for SVN is in creating that object model and
> implementing it out of the C binding. Once there is an object model it
> will be easy enough to implement in all the languages. Maybe SWIGing
> the C++ binding for SVN that RapidSVN(?) has is a better approach?
Hmm... that's certainly worth exploring. It unfortunately means we'd
have to maintain the C++ wrapper, the SWIG bindings of that wrapper,
and then (probably) some addition language-specific cleanup code atop
that. But if the C++ API coverage is superb, maybe that's not such a
terrible thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 04-10-2003 14:17, C. Michael Pilato wrote:
>Barry Scott <ba...@barrys-emacs.org> writes:
>
> > I'm just checked to see what the state of Python API was in the issues.
> > There is one issue 1451. Is it still you're intention to ship 1.0
> > without a scripting API that works? In my world this is a gating
> > factor for adoption of subversion. I'm not trying to change your
> > mind on release criteria, I just want to know when this will be
> > important enough to make work. Then I can plan what I do accordingly.
snip...
>While I think the scripting language is important, I disagree on your
>assertion that it needs to be perfected for 1.0. In my mind,
I never asserted that. I asked for confirmation. You have confirmed that
1.1 is what I will need to wait for. I'll help how I can towards 1.1 for
the bindings.
>Subversion 1.0 is about providing the tools and backing libraries to
>give folks a real excuse to leave their crummy old CVS behind and
>never look back. We will do this.
>
>I *would*, however, like to see our bindings shaped up -- with
>dedicated maintainers for each supported language -- by Subversion
>1.1. And that means (IMO) a few things:
>
> - consolidation of effort: SWIG is a great tool that can go the
> distance if we can take the time to tune the interface files. It
> bothers me that I can't talk about "the Java bindings" without
> having to state which one I'm talking about.
>
> - consolidation of design: while SWIG can do the gruntwork of
> wrapping C APIs, there is a level of language-friendly work that
> needs to be designed on top of the SWIG output. Ideally, these
> efforts would also be coordinated across the languages, with
> specific design goals that are shared by them all.
>
>The best binding set I've ever seen is that for the wxWindows library.
>The documentation for all the bindings languages is so similar that
>it's all in one doc-set, with little footnotes for language-specific
>exceptions where they happen. And it's all SWIG + an extra layer,
>unless I'm mistaken. *That's* what I want to see for Subversion.
wxPython is very good. We build all our GUI tools using it at work.
There is very little in the extra layer. 99% of the .py is generated
out of SWIG (that begs the question of what they do in the .i files).
They do the prefix striping.
wxPython has a simpler job as wxWndows is OO so they have the object
model. The design work for SVN is in creating that object model and
implementing it out of the C binding. Once there is an object model it
will be easy enough to implement in all the languages. Maybe SWIGing
the C++ binding for SVN that RapidSVN(?) has is a better approach?
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 04-10-2003 14:17, C. Michael Pilato wrote:
>Barry Scott <ba...@barrys-emacs.org> writes:
>
> > I'm just checked to see what the state of Python API was in the issues.
> > There is one issue 1451. Is it still you're intention to ship 1.0
> > without a scripting API that works? In my world this is a gating
> > factor for adoption of subversion. I'm not trying to change your
> > mind on release criteria, I just want to know when this will be
> > important enough to make work. Then I can plan what I do accordingly.
snip...
>While I think the scripting language is important, I disagree on your
>assertion that it needs to be perfected for 1.0. In my mind,
I never asserted that. I asked for confirmation. You have confirmed that
1.1 is what I will need to wait for. I'll help how I can towards 1.1 for
the bindings.
>Subversion 1.0 is about providing the tools and backing libraries to
>give folks a real excuse to leave their crummy old CVS behind and
>never look back. We will do this.
>
>I *would*, however, like to see our bindings shaped up -- with
>dedicated maintainers for each supported language -- by Subversion
>1.1. And that means (IMO) a few things:
>
> - consolidation of effort: SWIG is a great tool that can go the
> distance if we can take the time to tune the interface files. It
> bothers me that I can't talk about "the Java bindings" without
> having to state which one I'm talking about.
>
> - consolidation of design: while SWIG can do the gruntwork of
> wrapping C APIs, there is a level of language-friendly work that
> needs to be designed on top of the SWIG output. Ideally, these
> efforts would also be coordinated across the languages, with
> specific design goals that are shared by them all.
>
>The best binding set I've ever seen is that for the wxWindows library.
>The documentation for all the bindings languages is so similar that
>it's all in one doc-set, with little footnotes for language-specific
>exceptions where they happen. And it's all SWIG + an extra layer,
>unless I'm mistaken. *That's* what I want to see for Subversion.
wxPython is very good. We build all our GUI tools using it at work.
There is very little in the extra layer. 99% of the .py is generated
out of SWIG (that begs the question of what they do in the .i files).
They do the prefix striping.
wxPython has a simpler job as wxWndows is OO so they have the object
model. The design work for SVN is in creating that object model and
implementing it out of the C binding. Once there is an object model it
will be easy enough to implement in all the languages. Maybe SWIGing
the C++ binding for SVN that RapidSVN(?) has is a better approach?
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> I'm just checked to see what the state of Python API was in the issues.
> There is one issue 1451. Is it still you're intention to ship 1.0
> without a scripting API that works? In my world this is a gating
> factor for adoption of subversion. I'm not trying to change your
> mind on release criteria, I just want to know when this will be
> important enough to make work. Then I can plan what I do accordingly.
>
> I'll keep working with Russell to get svn.client working to help
> get this usable. But I fear that at some point we will run out of
> knowledge of how subversion and its bindings are supposed to work and
> will need help from a core developer.
While I think the scripting language is important, I disagree on your
assertion that it needs to be perfected for 1.0. In my mind,
Subversion 1.0 is about providing the tools and backing libraries to
give folks a real excuse to leave their crummy old CVS behind and
never look back. We will do this.
I *would*, however, like to see our bindings shaped up -- with
dedicated maintainers for each supported language -- by Subversion
1.1. And that means (IMO) a few things:
- consolidation of effort: SWIG is a great tool that can go the
distance if we can take the time to tune the interface files. It
bothers me that I can't talk about "the Java bindings" without
having to state which one I'm talking about.
- consolidation of design: while SWIG can do the gruntwork of
wrapping C APIs, there is a level of language-friendly work that
needs to be designed on top of the SWIG output. Ideally, these
efforts would also be coordinated across the languages, with
specific design goals that are shared by them all.
The best binding set I've ever seen is that for the wxWindows library.
The documentation for all the bindings languages is so similar that
it's all in one doc-set, with little footnotes for language-specific
exceptions where they happen. And it's all SWIG + an extra layer,
unless I'm mistaken. *That's* what I want to see for Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Barry Scott <ba...@barrys-emacs.org> writes:
> I'm just checked to see what the state of Python API was in the issues.
> There is one issue 1451. Is it still you're intention to ship 1.0
> without a scripting API that works? In my world this is a gating
> factor for adoption of subversion. I'm not trying to change your
> mind on release criteria, I just want to know when this will be
> important enough to make work. Then I can plan what I do accordingly.
>
> I'll keep working with Russell to get svn.client working to help
> get this usable. But I fear that at some point we will run out of
> knowledge of how subversion and its bindings are supposed to work and
> will need help from a core developer.
While I think the scripting language is important, I disagree on your
assertion that it needs to be perfected for 1.0. In my mind,
Subversion 1.0 is about providing the tools and backing libraries to
give folks a real excuse to leave their crummy old CVS behind and
never look back. We will do this.
I *would*, however, like to see our bindings shaped up -- with
dedicated maintainers for each supported language -- by Subversion
1.1. And that means (IMO) a few things:
- consolidation of effort: SWIG is a great tool that can go the
distance if we can take the time to tune the interface files. It
bothers me that I can't talk about "the Java bindings" without
having to state which one I'm talking about.
- consolidation of design: while SWIG can do the gruntwork of
wrapping C APIs, there is a level of language-friendly work that
needs to be designed on top of the SWIG output. Ideally, these
efforts would also be coordinated across the languages, with
specific design goals that are shared by them all.
The best binding set I've ever seen is that for the wxWindows library.
The documentation for all the bindings languages is so similar that
it's all in one doc-set, with little footnotes for language-specific
exceptions where they happen. And it's all SWIG + an extra layer,
unless I'm mistaken. *That's* what I want to see for Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
I'm just checked to see what the state of Python API was in the issues.
There is one issue 1451. Is it still you're intention to ship 1.0
without a scripting API that works? In my world this is a gating
factor for adoption of subversion. I'm not trying to change your
mind on release criteria, I just want to know when this will be
important enough to make work. Then I can plan what I do accordingly.
I'll keep working with Russell to get svn.client working to help
get this usable. But I fear that at some point we will run out of
knowledge of how subversion and its bindings are supposed to work and
will need help from a core developer.
BArry
At 03-10-2003 05:50, kfogel@collab.net wrote:
>A lot of folks have been asking, "What's up with the issues marked for
>the '1.0' milestone? Are they after Beta, or before Beta, or what?"
>
>Okay, actually no one's been asking that. But I wanted start with a
>leading question, so I could pretend to answer it...
>
>The "1.0" milestone has been a dumping ground for issues that are
>nice-to-haves for a 1.0 release, but not truly required. I won't talk
>about particular issues here; anyone looking over the 25 or so "1.0"
>bugs can come to their own conclusions about which ones are important
>to fix before 1.0 and which aren't. And probably not come to exactly
>the same conclusion as someone else would, either :-).
>
>Over the next day, you'll see me moving many of them to a new "1.1"
>milestone, our first gradation in the hitherto-monolithic "Post-1.0"
>category. The rest will get moved to 0.32 or into the general
>Post-1.0 pool. None will be left in 1.0, because the only purpose of
>that milestone was as a holding area until we got to this point.
>
>I hope people are generally okay with this. I certainly don't expect
>everyone to agree with every decision, but do ask that you wait until
>you have an overview of all the shifts before objecting to a
>particular assignation. Some serious triage is necessary, or we'll be
>here all day, know what I mean? :-)
>
>As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
>are officially "in Beta". At that point, we will make a release
>branch (called "stabilize-1.0" or something), which will be for
>bugfixes only. There will be cross-pollination between trunk and the
>1.0 stabilization branch, but risky new features will stay confined to
>trunk. When the branch is ready, we release 1.0, and have a party.
>
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Barry Scott <ba...@barrys-emacs.org>.
I'm just checked to see what the state of Python API was in the issues.
There is one issue 1451. Is it still you're intention to ship 1.0
without a scripting API that works? In my world this is a gating
factor for adoption of subversion. I'm not trying to change your
mind on release criteria, I just want to know when this will be
important enough to make work. Then I can plan what I do accordingly.
I'll keep working with Russell to get svn.client working to help
get this usable. But I fear that at some point we will run out of
knowledge of how subversion and its bindings are supposed to work and
will need help from a core developer.
BArry
At 03-10-2003 05:50, kfogel@collab.net wrote:
>A lot of folks have been asking, "What's up with the issues marked for
>the '1.0' milestone? Are they after Beta, or before Beta, or what?"
>
>Okay, actually no one's been asking that. But I wanted start with a
>leading question, so I could pretend to answer it...
>
>The "1.0" milestone has been a dumping ground for issues that are
>nice-to-haves for a 1.0 release, but not truly required. I won't talk
>about particular issues here; anyone looking over the 25 or so "1.0"
>bugs can come to their own conclusions about which ones are important
>to fix before 1.0 and which aren't. And probably not come to exactly
>the same conclusion as someone else would, either :-).
>
>Over the next day, you'll see me moving many of them to a new "1.1"
>milestone, our first gradation in the hitherto-monolithic "Post-1.0"
>category. The rest will get moved to 0.32 or into the general
>Post-1.0 pool. None will be left in 1.0, because the only purpose of
>that milestone was as a holding area until we got to this point.
>
>I hope people are generally okay with this. I certainly don't expect
>everyone to agree with every decision, but do ask that you wait until
>you have an overview of all the shifts before objecting to a
>particular assignation. Some serious triage is necessary, or we'll be
>here all day, know what I mean? :-)
>
>As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
>are officially "in Beta". At that point, we will make a release
>branch (called "stabilize-1.0" or something), which will be for
>bugfixes only. There will be cross-pollination between trunk and the
>1.0 stabilization branch, but risky new features will stay confined to
>trunk. When the branch is ready, we release 1.0, and have a party.
>
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
kfogel@collab.net writes:
> Greg Hudson <gh...@MIT.EDU> writes:
> > Is it really a good idea to branch at beta? Do we really want to try to
> > be stabilizing for 1.0 at the same time as we're adding features to the
> > trunk? It seems wiser to just declare a tight feature freeze and have
> > our whole community behind the same trunk.
> >
> > I'd say the appropriate time to branch is when we want to prepare for a
> > 1.0.1 release.
>
> What Greg Stein said -- I personally would prefer to just feature
> freeze the trunk and lay off the new features entirely for a while. I
> just assumed (perhaps wrongly) that a lot of developers wouldn't go
> for that.
>
> Would anyone object to a trunk feature freeze during Beta?
Not I. Certainly people are here as volunteers, but calling a trunk
feature freeze just might help to focus the community on 1.0 instead of
focusing just a few people on 1.0.
-Fitz, onward to 1.0!
--
Brian W. Fitzpatrick <fi...@red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
binary compat (was: 0.32, the "1.0" milestone, and the 1.0 release.)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 07, 2003 at 10:18:54PM -0700, Justin Erenkrantz wrote:
>...
> IMHO, the more pressing need for 1.0 is the binary compatibility rules. They
> go in force once we hit 1.0. Therefore, *no* commits can hit the trunk that
> break compatibility. That was our big mistake with httpd-2.0. -- justin
For people who don't know the rules we're using:
http://apr.apache.org/versioning.html
I thought I had this reference in svn_version.h, but it appears to be
missing. Hmm. In any case, the rules for updating numbers in svn_version.h
are tightly bound to the rules in the above-ref'd document.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> My concern about having a frozen trunk is that if someone wants to
> work on, say, redoing libsvn_wc, they don't have a place to work on
> it. But, aha, there's a neat thing called branching which this cool
> SCM system called Subversion does cheaply. ;-)
>
> So, +1 to a trunk feature freeze as long as anyone wanting to do
> something particularly dramatic does so on a branch.
Yup. Frankly, they'd probably use a branch for that particular work
even if trunk weren't frozen for release...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, October 3, 2003 9:07 AM -0500 kfogel@collab.net wrote:
> Would anyone object to a trunk feature freeze during Beta?
My concern about having a frozen trunk is that if someone wants to work on,
say, redoing libsvn_wc, they don't have a place to work on it. But, aha,
there's a neat thing called branching which this cool SCM system called
Subversion does cheaply. ;-)
So, +1 to a trunk feature freeze as long as anyone wanting to do something
particularly dramatic does so on a branch.
IMHO, the more pressing need for 1.0 is the binary compatibility rules. They
go in force once we hit 1.0. Therefore, *no* commits can hit the trunk that
break compatibility. That was our big mistake with httpd-2.0. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Blair Zajac <bl...@orcaware.com>.
kfogel@collab.net wrote:
>
> Greg Hudson <gh...@MIT.EDU> writes:
> > Is it really a good idea to branch at beta? Do we really want to try to
> > be stabilizing for 1.0 at the same time as we're adding features to the
> > trunk? It seems wiser to just declare a tight feature freeze and have
> > our whole community behind the same trunk.
> >
> > I'd say the appropriate time to branch is when we want to prepare for a
> > 1.0.1 release.
>
> What Greg Stein said -- I personally would prefer to just feature
> freeze the trunk and lay off the new features entirely for a while. I
> just assumed (perhaps wrongly) that a lot of developers wouldn't go
> for that.
>
> Would anyone object to a trunk feature freeze during Beta?
No. I'd like to see a 1.0 out soon and this would be the number one
priority. Having 1.0 now on the trunk would, for me at least, give a
message to the community that this is the number one priority.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Is it really a good idea to branch at beta? Do we really want to try to
> be stabilizing for 1.0 at the same time as we're adding features to the
> trunk? It seems wiser to just declare a tight feature freeze and have
> our whole community behind the same trunk.
>
> I'd say the appropriate time to branch is when we want to prepare for a
> 1.0.1 release.
What Greg Stein said -- I personally would prefer to just feature
freeze the trunk and lay off the new features entirely for a while. I
just assumed (perhaps wrongly) that a lot of developers wouldn't go
for that.
Would anyone object to a trunk feature freeze during Beta?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by mark benedetto king <mb...@lowlatency.com>.
On Fri, Oct 03, 2003 at 10:48:20AM -0500, kfogel@collab.net wrote:
> 2. Stabilize trunk, and just don't do new feature development until
> 1.0 is out.
>
> (2) has a bigger impact on developers who might want to work on new
> features. It effectively asks them to forgo that work, and either sit
> tight or help fix bugs instead.
>
> > So, I'm -0 on using the trunk as the release branch, but only because
> > it might blur the changes made on other branches and merged in later.
> > If we can agree to focus only on bugfixes, then I'm +1 on using the
> > trunk; that way there's no merging at all.
>
> Exactly, me too.
>
> Would any developers be very uncomfortable with (2)? It would be
> great if we all felt pretty much the same way about the relative
> priority of 1.0 versus new feature dev at this time... But I don't
> want to presume.
My point was that if they can't help but work on some non-1.0 feature,
they can always do the work on a branch. Then there's no presumption
required; individuals will need to weigh their desire to work on something
new against the extra hassle of the merge required later.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by kf...@collab.net.
mark benedetto king <mb...@lowlatency.com> writes:
> I don't see a big difference between these two scenarios:
>
> 1.) a pre-1.0 (or beta, or whatever) branch, doing only bugfixes to it
> while doing potentially destabilizing work on the trunk (and merging
> the bugfixes from the branch into the trunk)
>
> and
>
> 2.) a feature freeze on the trunk, doing only bugfixes to it, while
> doing potentially destabilizing work on branches (and eventually
> merging them all into the trunk after the 1.0 release).
Those aren't really the scenarios we're contemplating. Rather, it's a
question of
1. Continue regular development, including new features, on trunk,
while using a stabilization branch for 1.0? Or,
2. Stabilize trunk, and just don't do new feature development until
1.0 is out.
(2) has a bigger impact on developers who might want to work on new
features. It effectively asks them to forgo that work, and either sit
tight or help fix bugs instead.
> So, I'm -0 on using the trunk as the release branch, but only because
> it might blur the changes made on other branches and merged in later.
> If we can agree to focus only on bugfixes, then I'm +1 on using the
> trunk; that way there's no merging at all.
Exactly, me too.
Would any developers be very uncomfortable with (2)? It would be
great if we all felt pretty much the same way about the relative
priority of 1.0 versus new feature dev at this time... But I don't
want to presume.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by mark benedetto king <mb...@lowlatency.com>.
On Fri, Oct 03, 2003 at 02:00:04AM -0400, Greg Hudson wrote:
> On Fri, 2003-10-03 at 00:50, kfogel@collab.net wrote:
> > As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
> > are officially "in Beta". At that point, we will make a release
> > branch (called "stabilize-1.0" or something), which will be for
> > bugfixes only. There will be cross-pollination between trunk and the
> > 1.0 stabilization branch, but risky new features will stay confined to
> > trunk. When the branch is ready, we release 1.0, and have a party.
>
> Is it really a good idea to branch at beta? Do we really want to try to
> be stabilizing for 1.0 at the same time as we're adding features to the
> trunk? It seems wiser to just declare a tight feature freeze and have
> our whole community behind the same trunk.
>
One of the real strong points of svn is that branches aren't really that
different from the trunk.
I don't see a big difference between these two scenarios:
1.) a pre-1.0 (or beta, or whatever) branch, doing only bugfixes to it
while doing potentially destabilizing work on the trunk (and merging
the bugfixes from the branch into the trunk)
and
2.) a feature freeze on the trunk, doing only bugfixes to it, while
doing potentially destabilizing work on branches (and eventually
merging them all into the trunk after the 1.0 release).
The biggest difference that comes to mind is the revision-history blindspot
created by merging; it might be nicer in this respect to do the as much work
as possible directly on the trunk. However, we have this same problem
already for the changes that are produced on branches.
So, I'm -0 on using the trunk as the release branch, but only because
it might blur the changes made on other branches and merged in later.
If we can agree to focus only on bugfixes, then I'm +1 on using the
trunk; that way there's no merging at all.
---ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Oct 03, 2003 at 02:00:04AM -0400, Greg Hudson wrote:
> On Fri, 2003-10-03 at 00:50, kfogel@collab.net wrote:
> > As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
> > are officially "in Beta". At that point, we will make a release
> > branch (called "stabilize-1.0" or something), which will be for
> > bugfixes only. There will be cross-pollination between trunk and the
> > 1.0 stabilization branch, but risky new features will stay confined to
> > trunk. When the branch is ready, we release 1.0, and have a party.
>
> Is it really a good idea to branch at beta? Do we really want to try to
> be stabilizing for 1.0 at the same time as we're adding features to the
> trunk? It seems wiser to just declare a tight feature freeze and have
> our whole community behind the same trunk.
That is a very good question. The concept of a stabilization branch is
based upon the premise that people are here as volunteers, and many with
conflicting goals. There are people who really want to see 1.0 produced,
and others that are more interested in what SVN can do for them [and the
1.0 label is irrelevant]. A mechanism to manage those conflicting
directions is a stabilization branch: each "sub-community" (if you will)
can work on the branch that interests them. Those who strive for 1.0 will
concentrate on the branch. Those that are uninterested will continue
working on the trunk.
Your suggestion assumes the dev community is only working towards 1.0, or
that they are willing to refrain from their own work/interests while the
other portions of the community are persuing 1.0.
Yet another possibility is that we don't actually have these envisioned
subcommunities :-)
Personally, I'm quite happy to stabilize on the trunk. My only concern is
if people will take issue with being told, "sorry. not going to apply that
patch" or "that bugfix is too risky" or "we don't want that config option"
or whatever it might be. Moving from "0.32 done. call it beta." to the
final 1.0 could mean *weeks* without a commit. The said (unsaid?) desire
is to provide "soak time" to see if bugs come in that we haven't seen yet.
And (IMO) a good soak time is measured in weeks. Get a bug report, fix it,
and then go for another couple weeks. Repeat :-)
Is the resulting "sorry, no commits" pressure (over an extended period)
sustainable by the SVN dev community? I really have no idea. With my
CollabNet hat on, I can certainly say, "sure. we have no problem with a
no-commits soak time." But we *are* a minority in this community.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 0.32, the "1.0" milestone, and the 1.0 release.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-10-03 at 00:50, kfogel@collab.net wrote:
> As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
> are officially "in Beta". At that point, we will make a release
> branch (called "stabilize-1.0" or something), which will be for
> bugfixes only. There will be cross-pollination between trunk and the
> 1.0 stabilization branch, but risky new features will stay confined to
> trunk. When the branch is ready, we release 1.0, and have a party.
Is it really a good idea to branch at beta? Do we really want to try to
be stabilizing for 1.0 at the same time as we're adding features to the
trunk? It seems wiser to just declare a tight feature freeze and have
our whole community behind the same trunk.
I'd say the appropriate time to branch is when we want to prepare for a
1.0.1 release.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org