You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2013/04/10 17:34:12 UTC
Let's branch on Friday. (was: "Re: 1.8 new public API review (mostly)
complete.")
On 04/10/2013 11:23 AM, Julian Foad wrote:
> So shall we get this branch branched very soon? For the sake of making a
> decision, I'll suggest that we should try hard to get the things above
> resolved by the end of tomorrow, and that even if we don't they are not
> blockers, so:
>
> Let's branch on Friday.
>
> Any support or objections?
None. In fact, thanks to your email, I had to discard my own draft mail
which said similar things but suggested we branch on Monday. :-)
(Paul, Bert: If you're watching for that mail from me, it won't get sent
now -- we can discuss and +1 on this thread just as easily.)
+1 to a Friday branch unless folks raise reasonable objections.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Let's branch on Friday.
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> On 04/12/2013 01:36 PM, Julian Foad wrote:
>> I'll branch at about 18:30 UTC (less than an hour from now) if all
>> still looks well at that time.
>
> Sounds good.
r1467414: Branch created.
r1467415: Trunk version number bumped.
r1467428: STATUS file added on branch.
>> The releasing guidelines say to create the CHANGES section for 1.8 on
>> trunk after branching, but that was done long ago. In fact, we probably
>> want to add a CHANGES section for 1.9 soon after branching.
>
> Yup.
r1467432: Added a 1.9.0 section to CHANGES on trunk.
>> Do we want to produce a tarball immediately? I'm not clear on this. I
>> haven't read up on what to do, nor done it before, but if we do want to
>> then I could probably do it this afternoon if it's not too involved, or
>> on Monday. Or I'd be happy if someone else wants to do it.
>
> I got the sense from a prior thread that not many folks care about the
> pre-RC stuffs. We know the branch isn't RC-ready, so if we cut a tarball,
> it would be "beta1". And then I'd suggest we not cut any more
> until we were
> ready for "rc1".
>
> I say, if you (or Ben or anyone else) has the energy and interest and making
> a "beta1" tarball, just do it. Folks will either sign the thing or
> they won't. :-)
OK, I won't do a tarball unless we discuss further and decide we should.
- Julian
Re: Let's branch on Friday.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/12/2013 02:15 PM, Philip Martin wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
>> We know the branch isn't RC-ready, so if we cut a tarball, it would be
>> "beta1".
>
> What needs to happen to make it RC-ready?
*
http://subversion.tigris.org/issues/buglist.cgi?target_milestone=1.8.0&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED
* CHANGES
* known-to-be-forthcoming localization stuffs (per IRC)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Let's branch on Friday.
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
>> We know the branch isn't RC-ready, so if we cut a tarball, it would be
>> "beta1".
>
> What needs to happen to make it RC-ready?
CHANGES needs to be completed. Anything else?
--
Philip
Re: Let's branch on Friday.
Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> We know the branch isn't RC-ready, so if we cut a tarball, it would be
> "beta1".
What needs to happen to make it RC-ready?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Let's branch on Friday.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/12/2013 01:36 PM, Julian Foad wrote:
> I'll branch at about 18:30 UTC (less than an hour from now) if all still
> looks well at that time.
Sounds good.
> The releasing guidelines say to create the CHANGES section for 1.8 on
> trunk after branching, but that was done long ago. In fact, we probably
> want to add a CHANGES section for 1.9 soon after branching.
Yup.
> Do we want to produce a tarball immediately? I'm not clear on this. I
> haven't read up on what to do, nor done it before, but if we do want to
> then I could probably do it this afternoon if it's not too involved, or
> on Monday. Or I'd be happy if someone else wants to do it.
I got the sense from a prior thread that not many folks care about the
pre-RC stuffs. We know the branch isn't RC-ready, so if we cut a tarball,
it would be "beta1". And then I'd suggest we not cut any more until we were
ready for "rc1".
I say, if you (or Ben or anyone else) has the energy and interest and making
a "beta1" tarball, just do it. Folks will either sign the thing or they
won't. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Let's branch on Friday. (was: "Re: 1.8 new public API review (mostly) complete.")
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Fuhrmann wrote:
> C. Michael Pilato wrote:
>> Julian Foad wrote:
>>> So shall we get this branch branched very soon? For the sake of making a
>>> decision, I'll suggest that we should try hard to get the things above
>>> resolved by the end of tomorrow, and that even if we don't they are not
>>> blockers, so:
>>>
>>> Let's branch on Friday.
>>>
>>> Any support or objections?
>>
>> None. [...]
>>
>> +1 to a Friday branch unless folks raise reasonable objections.
>
> +1. On track for a release party in Berlin.
Friday is here and from what I can see we're ready to branch. The API review is sufficiently complete. Three issues in the tracker are still marked with a 1.8.0 milestone, and were being discussed on IRC this morning, and it doesn't seem that they block branching.
I am ready to create the branch and, after branching, bump the trunk minor version number.
I'll branch at about 18:30 UTC (less than an hour from now) if all still looks well at that time.
The releasing guidelines say to create the CHANGES section for 1.8 on trunk after branching, but that was done long ago. In fact, we probably want to add a CHANGES section for 1.9 soon after branching.
Do we want to produce a tarball immediately? I'm not clear on this. I haven't read up on what to do, nor done it before, but if we do want to then I could probably do it this afternoon if it's not too involved, or on Monday. Or I'd be happy if someone else wants to do it.
- Julian
Re: Let's branch on Friday. (was: "Re: 1.8 new public API review
(mostly) complete.")
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Apr 10, 2013 at 5:34 PM, C. Michael Pilato <cm...@collab.net>wrote:
> On 04/10/2013 11:23 AM, Julian Foad wrote:
> > So shall we get this branch branched very soon? For the sake of making a
> > decision, I'll suggest that we should try hard to get the things above
> > resolved by the end of tomorrow, and that even if we don't they are not
> > blockers, so:
> >
> > Let's branch on Friday.
> >
> > Any support or objections?
>
> None. In fact, thanks to your email, I had to discard my own draft mail
> which said similar things but suggested we branch on Monday. :-)
>
(Paul, Bert: If you're watching for that mail from me, it won't get sent
> now -- we can discuss and +1 on this thread just as easily.)
>
> +1 to a Friday branch unless folks raise reasonable objections.
>
+1. On track for a release party in Berlin.
-- Stefan^2.
--
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
*
*
Re: Let's branch on Friday. (was: "Re: 1.8 new public API review
(mostly) complete.")
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, Apr 10, 2013 at 8:33 PM, Daniel Shahaf <da...@apache.org> wrote:
> On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
>> On 04/10/2013 11:23 AM, Julian Foad wrote:
>> > So shall we get this branch branched very soon? For the sake of making a
>> > decision, I'll suggest that we should try hard to get the things above
>> > resolved by the end of tomorrow, and that even if we don't they are not
>> > blockers, so:
>> >
>> > Let's branch on Friday.
>> >
>> > Any support or objections?
>>
>> None. In fact, thanks to your email, I had to discard my own draft mail
>> which said similar things but suggested we branch on Monday. :-)
>>
>> (Paul, Bert: If you're watching for that mail from me, it won't get sent
>> now -- we can discuss and +1 on this thread just as easily.)
>>
>> +1 to a Friday branch unless folks raise reasonable objections.
>
> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> command but not a UI for them. (Some of them have unit tests.) I think we
> don't want to release with just the half-backed APIs, so we'll have to either
> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> and I can continue the work on trunk and propose for backport before, say,
> beta1.
>
> This concerns svn_fs_info_* and svn_repos_info_*.
>From my experience such last minute API changes especially without
real usage/UI often leads to problems and release delays.
So I'm in favor to revert svn_repos_info*/svn_fs_info_* API on trunk,
make branch and bring API back with UI implementation.
Subversion 1.8 already has many useful features. And svnadmin info
would be first feature for 1.9. It would one more argument to release
1.9 earlier :)
--
Ivan Zhakov
Re: Compatibility-promise-less API's Re: Let's branch on Friday.
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Apr 11, 2013 at 08:00:30AM -0400, C. Michael Pilato wrote:
> The last thing we need is a new "class" of public APIs with special promises.
I agree, it would add too much extra complexity.
Our API rules are already quite complex.
Re: Compatibility-promise-less API's Re: Let's branch on Friday.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/10/2013 09:50 PM, Daniel Shahaf wrote:
>> That's unprecedented, we've never released an API "without compatibility
>> promises". We could do that but that's a separate discussion IMO.
>
> That might be a good idea. How about we introduce a class of public
> APIs, disabled by default (i.e., opt-in towards library consumers),
> which doesn't have any cross-minor-line (1.x <-> 1.y) compatibility
> promises? Or even, "doesn't have any compatibility promises", full
> stop: may change arbitrarily between 1.8.x and 1.8.y.
-1
Look, if we haven't found a decent use for our own API, and we don't have a
third-party client asking specifically for its (well-defined) functionality,
then that tells us the API is unnecessary. The last thing we need is a new
"class" of public APIs with special promises.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Compatibility-promise-less API's Re: Let's branch on Friday.
Posted by Daniel Shahaf <da...@elego.de>.
Ivan Zhakov wrote on Thu, Apr 11, 2013 at 13:24:32 +0400:
> On Thu, Apr 11, 2013 at 5:50 AM, Daniel Shahaf <da...@elego.de> wrote:
> > Daniel Shahaf wrote on Thu, Apr 11, 2013 at 02:28:30 +0300:
> >> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400:
> >> > On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf <da...@elego.de> wrote:
> >> > > Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
> >> > >> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
> >> > >> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
> >> > >> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> >> > >> >> command but not a UI for them. (Some of them have unit tests.) I think we
> >> > >> >> don't want to release with just the half-backed APIs, so we'll have to either
> >> > >> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> >> > >> >> and I can continue the work on trunk and propose for backport before, say,
> >> > >> >> beta1.
> >> > >> >
> >> > >> > Either revert or privatize them -- whatever's easiest. Now's really not the
> >> > >> > best time to be trying to introduce new UI, methinks.
> >> > >> >
> >> > >> +1
> >> > >
> >> > > Made them conditional on -DSVN_FS_INFO.
> >> > I think it's better to make API private instead of ifdef:
> >> > 1. svn_repos.h/svn_fs.h readers might be confused with this ifdef
> > ...
> >> > 2. Private API still allow to use this functionality by svn 1.8 API
> >> > users with disclaimer that this may change in svn 1.9.
> >>
> >> That's unprecedented, we've never released an API "without compatibility
> >> promises". We could do that but that's a separate discussion IMO.
> >
> I believe that we do not promise compatibility for private API.
We also don't permit code we didn't write to call such APIs. (e.g., we
don't install include/private/ during 'make install' --- just like we
don't install subversion/libsvn_*/*.h)
Re: Compatibility-promise-less API's Re: Let's branch on Friday.
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Apr 11, 2013 at 5:50 AM, Daniel Shahaf <da...@elego.de> wrote:
> Daniel Shahaf wrote on Thu, Apr 11, 2013 at 02:28:30 +0300:
>> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400:
>> > On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf <da...@elego.de> wrote:
>> > > Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
>> > >> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> > >> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
>> > >> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
>> > >> >> command but not a UI for them. (Some of them have unit tests.) I think we
>> > >> >> don't want to release with just the half-backed APIs, so we'll have to either
>> > >> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
>> > >> >> and I can continue the work on trunk and propose for backport before, say,
>> > >> >> beta1.
>> > >> >
>> > >> > Either revert or privatize them -- whatever's easiest. Now's really not the
>> > >> > best time to be trying to introduce new UI, methinks.
>> > >> >
>> > >> +1
>> > >
>> > > Made them conditional on -DSVN_FS_INFO.
>> > I think it's better to make API private instead of ifdef:
>> > 1. svn_repos.h/svn_fs.h readers might be confused with this ifdef
> ...
>> > 2. Private API still allow to use this functionality by svn 1.8 API
>> > users with disclaimer that this may change in svn 1.9.
>>
>> That's unprecedented, we've never released an API "without compatibility
>> promises". We could do that but that's a separate discussion IMO.
>
I believe that we do not promise compatibility for private API.
--
Ivan Zhakov
Compatibility-promise-less API's Re: Let's branch on Friday.
Posted by Daniel Shahaf <da...@elego.de>.
Daniel Shahaf wrote on Thu, Apr 11, 2013 at 02:28:30 +0300:
> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400:
> > On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf <da...@elego.de> wrote:
> > > Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
> > >> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
> > >> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
> > >> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> > >> >> command but not a UI for them. (Some of them have unit tests.) I think we
> > >> >> don't want to release with just the half-backed APIs, so we'll have to either
> > >> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> > >> >> and I can continue the work on trunk and propose for backport before, say,
> > >> >> beta1.
> > >> >
> > >> > Either revert or privatize them -- whatever's easiest. Now's really not the
> > >> > best time to be trying to introduce new UI, methinks.
> > >> >
> > >> +1
> > >
> > > Made them conditional on -DSVN_FS_INFO.
> > I think it's better to make API private instead of ifdef:
> > 1. svn_repos.h/svn_fs.h readers might be confused with this ifdef
...
> > 2. Private API still allow to use this functionality by svn 1.8 API
> > users with disclaimer that this may change in svn 1.9.
>
> That's unprecedented, we've never released an API "without compatibility
> promises". We could do that but that's a separate discussion IMO.
That might be a good idea. How about we introduce a class of public
APIs, disabled by default (i.e., opt-in towards library consumers),
which doesn't have any cross-minor-line (1.x <-> 1.y) compatibility
promises? Or even, "doesn't have any compatibility promises", full
stop: may change arbitrarily between 1.8.x and 1.8.y.
The idea is to make new APIs more widely available for consumption and
testing; currently, the only exposure new APIs get is by (a) third party
consumers who use trunk code, (b) the alpha/beta/rc cycle.
And I nominate the svn_fs_info_*/svn_repos_info_* set of APIs to be
released in 1.8.x as part of this new "No compat" mode. They can be
(modified as needed, and then) upgraded to the normal compatibility
rules in 1.9.x.
As to implementation, I see a few options. We could hide those APIs
with a preprocessor flag, or name them differently (e.g.,
svn_${library}_X_*), or make them an unconditional runtime error unless
getenv("USE_SVN_X_svn_fs_info_format") != NULL, etc.
Re: Let's branch on Friday.
Posted by Daniel Shahaf <da...@elego.de>.
Ivan Zhakov wrote on Wed, Apr 10, 2013 at 23:33:01 +0400:
> On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf <da...@elego.de> wrote:
> > Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
> >> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
> >> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
> >> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> >> >> command but not a UI for them. (Some of them have unit tests.) I think we
> >> >> don't want to release with just the half-backed APIs, so we'll have to either
> >> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> >> >> and I can continue the work on trunk and propose for backport before, say,
> >> >> beta1.
> >> >
> >> > Either revert or privatize them -- whatever's easiest. Now's really not the
> >> > best time to be trying to introduce new UI, methinks.
> >> >
> >> +1
> >
> > Made them conditional on -DSVN_FS_INFO.
> I think it's better to make API private instead of ifdef:
> 1. svn_repos.h/svn_fs.h readers might be confused with this ifdef
I'm happy to just delete the #ifdef's sections on the branch altogether.
I tend to do that post-branch though.
> 2. Private API still allow to use this functionality by svn 1.8 API
> users with disclaimer that this may change in svn 1.9.
That's unprecedented, we've never released an API "without compatibility
promises". We could do that but that's a separate discussion IMO.
Re: Let's branch on Friday.
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, Apr 10, 2013 at 10:02 PM, Daniel Shahaf <da...@elego.de> wrote:
> Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
>> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
>> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
>> >> command but not a UI for them. (Some of them have unit tests.) I think we
>> >> don't want to release with just the half-backed APIs, so we'll have to either
>> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
>> >> and I can continue the work on trunk and propose for backport before, say,
>> >> beta1.
>> >
>> > Either revert or privatize them -- whatever's easiest. Now's really not the
>> > best time to be trying to introduce new UI, methinks.
>> >
>> +1
>
> Made them conditional on -DSVN_FS_INFO.
I think it's better to make API private instead of ifdef:
1. svn_repos.h/svn_fs.h readers might be confused with this ifdef
2. Private API still allow to use this functionality by svn 1.8 API
users with disclaimer that this may change in svn 1.9.
--
Ivan Zhakov
Re: Let's branch on Friday.
Posted by Daniel Shahaf <da...@elego.de>.
Ivan Zhakov wrote on Wed, Apr 10, 2013 at 21:48:39 +0400:
> On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
> > On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
> >> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> >> command but not a UI for them. (Some of them have unit tests.) I think we
> >> don't want to release with just the half-backed APIs, so we'll have to either
> >> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> >> and I can continue the work on trunk and propose for backport before, say,
> >> beta1.
> >
> > Either revert or privatize them -- whatever's easiest. Now's really not the
> > best time to be trying to introduce new UI, methinks.
> >
> +1
Made them conditional on -DSVN_FS_INFO.
Re: Let's branch on Friday.
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, Apr 10, 2013 at 9:44 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
>> On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
>>> On 04/10/2013 11:23 AM, Julian Foad wrote:
>>>> So shall we get this branch branched very soon? For the sake of making a
>>>> decision, I'll suggest that we should try hard to get the things above
>>>> resolved by the end of tomorrow, and that even if we don't they are not
>>>> blockers, so:
>>>>
>>>> Let's branch on Friday.
>>>>
>>>> Any support or objections?
>>>
>>> None. In fact, thanks to your email, I had to discard my own draft mail
>>> which said similar things but suggested we branch on Monday. :-)
>>>
>>> (Paul, Bert: If you're watching for that mail from me, it won't get sent
>>> now -- we can discuss and +1 on this thread just as easily.)
>>>
>>> +1 to a Friday branch unless folks raise reasonable objections.
>>
>> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
>> command but not a UI for them. (Some of them have unit tests.) I think we
>> don't want to release with just the half-backed APIs, so we'll have to either
>> revert them or add a UI for them. As far as I'm concerned reverting is fine,
>> and I can continue the work on trunk and propose for backport before, say,
>> beta1.
>
> Either revert or privatize them -- whatever's easiest. Now's really not the
> best time to be trying to introduce new UI, methinks.
>
+1
--
Ivan Zhakov
Re: Let's branch on Friday.
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/10/2013 12:33 PM, Daniel Shahaf wrote:
> On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
>> On 04/10/2013 11:23 AM, Julian Foad wrote:
>>> So shall we get this branch branched very soon? For the sake of making a
>>> decision, I'll suggest that we should try hard to get the things above
>>> resolved by the end of tomorrow, and that even if we don't they are not
>>> blockers, so:
>>>
>>> Let's branch on Friday.
>>>
>>> Any support or objections?
>>
>> None. In fact, thanks to your email, I had to discard my own draft mail
>> which said similar things but suggested we branch on Monday. :-)
>>
>> (Paul, Bert: If you're watching for that mail from me, it won't get sent
>> now -- we can discuss and +1 on this thread just as easily.)
>>
>> +1 to a Friday branch unless folks raise reasonable objections.
>
> Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
> command but not a UI for them. (Some of them have unit tests.) I think we
> don't want to release with just the half-backed APIs, so we'll have to either
> revert them or add a UI for them. As far as I'm concerned reverting is fine,
> and I can continue the work on trunk and propose for backport before, say,
> beta1.
Either revert or privatize them -- whatever's easiest. Now's really not the
best time to be trying to introduce new UI, methinks.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Let's branch on Friday. (was: "Re: 1.8 new public API review (mostly) complete.")
Posted by Daniel Shahaf <da...@apache.org>.
On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
> On 04/10/2013 11:23 AM, Julian Foad wrote:
> > So shall we get this branch branched very soon? For the sake of making a
> > decision, I'll suggest that we should try hard to get the things above
> > resolved by the end of tomorrow, and that even if we don't they are not
> > blockers, so:
> >
> > Let's branch on Friday.
> >
> > Any support or objections?
>
> None. In fact, thanks to your email, I had to discard my own draft mail
> which said similar things but suggested we branch on Monday. :-)
>
> (Paul, Bert: If you're watching for that mail from me, it won't get sent
> now -- we can discuss and +1 on this thread just as easily.)
>
> +1 to a Friday branch unless folks raise reasonable objections.
Right now, trunk has APIs backing an 'svnadmin info' (or 'svnlook info')
command but not a UI for them. (Some of them have unit tests.) I think we
don't want to release with just the half-backed APIs, so we'll have to either
revert them or add a UI for them. As far as I'm concerned reverting is fine,
and I can continue the work on trunk and propose for backport before, say,
beta1.
This concerns svn_fs_info_* and svn_repos_info_*.