[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Releasing 1.6

From: <kmradke_at_rockwellcollins.com>
Date: Fri, 8 Aug 2008 10:03:13 -0500

Stefan Sperling <stsp_at_elego.de> wrote on 08/08/2008 09:46:49 AM:
> On Fri, Aug 08, 2008 at 08:56:07AM -0500, kmradke_at_rockwellcollins.com
> > "C. Michael Pilato" <cmpilato_at_collab.net> wrote on 08/08/2008 08:27:20
> > [snip]
> >
> > > So, I am (and have been) struggling very hard to see a meaningful
> > difference
> > > between what is being proposed here, and what we did in the past. I
> > > people with direct experience in dealing with vendor releases
> > in
> > > favor of what Mark and Senthil are trying to do, and I see people
> > > zero relevant experience with the same speaking against it.
> > If the changes are server only changes, I think confusion will be
> > If the changes are client libs as well, things will get a lot more
> > confusing.
> The changes do indeed affect client libraries.
> > I.E. what should TortoiseSVN link against?
> That is their decision. I think this is essentially the same
> story, just a different vendor.
> > The Collabnet beta binaries were nice, but they were in fact just
> > early releases, not containing features that potentially won't
> > be merged into a future release. (I have no reason to believe
> > they wouldn't be merged eventually though...)
> There seems to be a big misunderstanding here:
> AFAIK, CollabNet is _not_ planning to add features which are not
> in trunk already. No one has ever said that this was intended.

No one ever said it wasn't either...

> So, yes, the features will be present in a future release, namely 1.6.
> They are already in trunk, and essentially complete (i.e. mainly need
> bugfixing). The fact that they are in trunk today means that the
> community has accepted them. It would not make sense to exclude
> them from the next release.


> > I guess I'd like more details on when Collabnet wants/needs
> > a release with new functionality. I'm making an assumption
> > that the changes they want/need require API and or WC format
> > changes, which is why 1.6 is being discussed...
> The changes under discussion are related to client-side authentication
> features, and do not require WC format changes.
> Some new client-side public API has been added. But as usual,
> the APIs are backward-compatible, so if a client compiled against
> stock 1.5 libraries does not run with the modified ones, there's
> a bug.
> The most user-visible change is that the client configuration files
> understand some new options. Old clients will just ignore these
> options. Subversion 1.6 will be able to use them.

Do these changes require a minor version number bump, or can
this just be something like 1.5.2 (beta), just like the
original 1.5.0 (beta) versions released by collabnet?

Kevin R.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-08 17:03:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.