couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 03:51:32 GMT
As Noah points out, there are ASF procedural issues that affect this
discussion. Part of making a release involves getting community input
on whether the release is a valid artefact. As such we need to be able
to refer to these "not-release" sets of bytes. Traditionally in SVN we
did this by creating and delting "tags". Though SVN's idea of tags is
pretty bad.

The current issue is how do we create general best-practice guidelines
for any ASF project that might be interested in using Git. A naming
scheme along with the specific ASF Git hosting code should be
considered to try and minimize the confusion across a theoretical
couple hundred projects employing a couple thousand committers.

>        In the above example, if someone downloaded and is currently running 1.1.1-rc1
and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and v1.1.1-rc2, why would be
confused?  More importantly, you released that, so why would you not want the user to be
able to see whether any changes between 1.1.1-rc1 and 1.1.1 final affect his deployment?

You're missing my concern. My concern is when someone comes to us and
say's, "I'm running 1.1.1" and then I spend a couple hours debugging
that they really meant "I'm running 1.1.1-rc1." Anyone that's not
scared of this needs to spend more time debugging bugs in community
IRC channels or mailing lists.

>        The git git repo has 366 tags right now.  In addition to releases from a
subproject that spun out, there are 337 tags representing releases (and RCs) that shipped.
 It captures a wonderful release history of the project.
>        These are the tags since (and including) the version I'm running:
> v1.7.4.4        Git
> v1.7.4.5        Git
> v1.7.5          Git 1.7.5
> v1.7.5-rc0      Git 1.7.5-rc0
> v1.7.5-rc1      Git 1.7.5-rc1
> v1.7.5-rc2      Git 1.7.5-rc2
> v1.7.5-rc3      Git 1.7.5-rc3
> v1.7.5.1        Git
> v1.7.5.2        Git
> v1.7.5.3        Git
> v1.7.5.4        Git
> v1.7.6          Git 1.7.6
> v1.7.6-rc0      Git 1.7.6-rc0
> v1.7.6-rc1      Git 1.7.6-rc1
> v1.7.6-rc2      Git 1.7.6-rc2
> v1.7.6-rc3      Git 1.7.6-rc3
> v1.7.6.1        Git
> v1.7.7-rc0      Git 1.7.7-rc0
>        I very well may be biased, but I don't find that confusing.

Nor do I, but that is absolutely not the way to think about the issue.
Anyone on the dev@ list is pretty much categorically disqualified from
making a decision on what's best here. Of course if you follow such a
list you'll have an idea on what the "right" release is. But if you're
not involved, or even if you're not involved in dev of anything, its
not inconceivable (I do know what that word means :) to make the
mistake that 1.1.1-rc1 is newer than 1.1.1.

View raw message