couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <dus...@spy.net>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 01:04:44 GMT

On Oct 20, 2011, at 10:51 AM, Paul Davis wrote:

> Yes, the "path" prefixes (path probably was a bard word in my original
> email) exists merely as a way to distinguish between "these are
> official releases and are immutable" and the "this is a temporary tag
> that I can fix if I screw up."

	Branches really make the best temporary tags.

> I'm trying to consider all the cases here (in the context of my OCD).
> Do we necessarily care about the rc tags once a release has been made?
> In a perfect world I would expect one tag per release and everything
> would be neat and tidy. If so, then we need to be able to remove old
> tags once they have been usurped by actual releases.

	I've always considered anything I give out to be a release.  This includes betas and RCs
and anything else.

> Consider it from the POV of a user as well. If you have 5-10 tags for
> a release (not out of the question) then each user looking for that
> release has to spend time figuring out which is the right tag. Which
> means that either our naming conventions have to be extremely clear
> (even then I've seen enough to know that we'll still get questions) or
> we need to have procedure to narrow down the set of tags once the
> release is made. I prefer procedure because it will minimize the
> number of times in the future that i have to spend time debugging the
> fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
> bug related to SpiderMonkey 1.7 and sealing.

	This is why semver suggests version and tag naming conventions.  There's just no confusion
if the version number and the tag number match.

	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?

	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 1.7.4.4
v1.7.4.5        Git 1.7.4.5
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 1.7.5.1
v1.7.5.2        Git 1.7.5.2
v1.7.5.3        Git 1.7.5.3
v1.7.5.4        Git 1.7.5.4
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 1.7.6.1
v1.7.7-rc0      Git 1.7.7-rc0

	I very well may be biased, but I don't find that confusing.

-- 
dustin sallings




Mime
View raw message