On Sat, Apr 02, 2005 at 04:36:20PM -0800, Justin Erenkrantz wrote:
> It wasn't done on a mailing list, so the feedback was limited to whomever
> was on IRC at that particular time. Since we want to solicit signatures
> before announcing, we now need to make the announcement more widespread
> (and I believe, necessitating an email).
Well of course, which is why you'd put the revision and the branch in
the email. I'm obviously not saying you just announce it on IRC.
> Therefore, I believe it needs to be clearer where the release originated
> from: rather than just a revision from a directory, an actual directory
> that contains the tag.
What's unclear about giving a revision and path? Could you really
believe that there is a full committer here that couldn't understand
that?
> Once we decide to do a release, then at the point, the release exists. We
> can't (or shouldn't!) change the tag. The only difference is whether we
> make (or, recommend, depending upon your perspective) the release public or
> not: i.e. is it a good release? But, the issue is that the version is
> done...goodness or not is the question.
Sure, and until we're sure it's good we want to discourage people from
using it. The point here is to formalize testing. Not to put the code
in the hands of people faster. We have to remember that no matter what
we do this is going to end up running live on somebody's machine as soon
as we make any public announcements. Even if we strongly urge people
not to.
We've been fortunate and the "bad releases" we've had have been
relatively minor problems. What happens when we have a bad release that
destorys data only on a particular platform that the RM doesn't have
access to?
> The release isn't official until we say it is. =)
> >If you absolutely must have a tag then name it 1.1.4-test or something
> >like that. If the release is okay then mv it to 1.1.4, if it's trashed
> >then we just delete it and never post that tarball and start over with
> >1.1.5.
> >
> >But I really do believe that creating a tag says "this is a release."
>
> Once we soliciting signatures, it means that it is a release. Hence, I
> feel it should be in tags/.
Bahh. Fine let's use your terms.
There should not be a tag for a "release" until it is an "official
release" as long as we're using a generic "tag" folder because the
status of the tag is completely ambiguous without digging around
elsewhere. Your repository shouldn't be ambigious.
What harm is calling it 1.1.4-test going to be until we refer to it as
"official?"
> >Frankly, I've always wondered why we don't have a "tags" directory and a
> >"releases" directory. It seems cluttered to have release tags mixed
> >with unrelated tags that we might want to use. Plus having a releases
> >directory enhances the communication factor that the tag represents.
> >
> >There can be a 1.1.4 in tags, but if we decide to never call it a
> >release for some reason it just wouldn't exist in releases.
>
> That would work fine and would address a lot of your concerns. I'd like to
> hear what others think about it first...
Ok...
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 02:53:31 2005