--On Tuesday, December 16, 2003 5:38 PM -0500 Greg Hudson <ghudson@MIT.EDU>
wrote:
> So, right now, if we put out 0.35.0, and it has a big bug, we put out
> 0.35.1. What happens in your scheme when we put out 1.1.2 and it has a
> big bug? Do we put out 1.1.2.1? Do we put out 1.1.3 even though 1.1.3
> would ordinarily come from a fresh branch?
Yes, I'd say it's 1.1.3. Under httpd versioning rules (which is essentially
what I'd like to see us follow), there would be no branches in the
'development' release models. It'd just be a tag (cp /trunk /tags/1.1.3). If
it doesn't work, who cares. Move on. There's no expectation of 'quality' or
'functionality' in a development release.
Only 'stable' would have a branch.
> I'm thinking, maybe we don't have to branch for unstable trunk
> releases. Just tar up the trunk at a particular revision, wait a few
> days or a week to make sure nobody finds any awful bugs applying to the
> time you tarred up the trunk, and release the tarball. If someone did
> discover an awful bug, try again as of the trunk revision the bug is
> fixed on.
Yes.
> The above discipline is not as robust as our practice for 0.x releases,
> nor is it as predictable. But it is less work and less complexity. And
> unlike today, people won't need to use interim releases for real work,
> and we won't be trying to put out interim releases every 2-3 weeks.
Right. Our 0.x releases are meant for mass consumption though, so we are
being very careful (rightfully so). However, once we have a 'stable' branch
out, we can feel free to issue dud 'unstable' releases.
For 'stable' releases, we should have branches and a refined testing policy,
but that's not what we want on /trunk for 'unstable' releases. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 07:58:39 2003