[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: Martin Furter <mf_at_rola.ch>
Date: Fri, 8 Aug 2008 20:13:17 +0200 (CEST)

On Thu, 7 Aug 2008, C. Michael Pilato wrote:

> Martin Furter wrote:
>> And STATUS already contains a few things for the next micro release.
>> Who cares if it's called 1.5.2 or 1.6.0?
> We should *all* care about such things. A new minor version may mean new
> APIs we live with for the foreseeable future. It may mean working copy
> format bumps. It may mean new repository formats. These aren't the kinds of
> things you just push onto the user base every 3 months because you're in some
> kind of unnatural hurry to whip out releases. Each minor release comes with
> promises; every promise paid for with maintenance effort. Please don't be so
> flippant about such matters.

I'm sorry, I didn't want to sound like that. Especially not for the
general case.

> Now, it might be true that right now, we've none of these "promise problem
> points" queued in the trunk since 1.5.0 was branched. If that's the case, we
> aren't paying that particular maintenance cost right now, so that doesn't
> count against doing 1.6.0 over 1.5.2. But as a general statement ... well,
> see my first paragraph.

Right. But look at the history of subversion. About 3 month after
(almost) every release a few smaller features had been committed to trunk.
Some with API changes, some without. But these features had to wait until
a 'big iron' had been committed which is 'worth a release'. I just wanted
to say "smaller things can be worth a release too" because I had to wait a
long time for some of the small ones.


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 20:13:41 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.