[ part about trunk releases snipped ]
> > Seeing that frequent releases have created a level of trust of active
> > development and support to a wide community already, I would like to
> suggest we
> > don't hold up patch level releases too long. If there's nothing to
> release, then
> > we shouldn't, but if there is, my preference would be to release per
> quarter
> > or 4 months.
>
> This comment doesn't make sense to me. "Patch releases" to me means
> things like Subversion 1.0.1, which we would release whenever we have a
> sufficient mass of important bugs to fix in Subversion 1.0.0. You don't
> typically do those things on a schedule. But "release per quarter or 4
> months" sounds like a schedule for new stable middle-number releases
> (the next one being either 1.1.0 or 1.2.0, depending on whether we go
> with even-odd).
Ok, then I might have taken Karl's comment about not releasing anything for
about half a year after 1.0 too litteral. From that I thought he was
collecting all bugfixes into carefully timed bugfix releases for which the first
release - if any - whould be approximately 6 months after 1.0. That seemed a bit
too long to me. On the other hand, I would understand that no 1.0.1 release
be made within a month after 1.0 to be able to collect enough bugfixes.
> I would actually hope that our schedule for new middle-number stable
> releases isn't too aggressive. We don't want a lot of different stable
> branches out there (it's hard to support), but neither do we want to
> force our users into making potentially traumatic upgrades every few
> months. So, I would say once a year or so is good for middle-number
> releases. I would also expect it to take us close to a year to
> implement any interesting new functionality.
I didn't mean to have to implement a great new feature every 2 months :-)
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 21 18:56:30 2003