couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Git_At_Apache_Guide" by NoahSlater
Date Sat, 19 Nov 2011 23:14:40 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Git_At_Apache_Guide" page has been changed by NoahSlater:
http://wiki.apache.org/couchdb/Git_At_Apache_Guide?action=diff&rev1=21&rev2=22

  Be aware that the branch created by a release with GIT always covers the whole repository.
  
  ==== Release Tags with GIT ====
- [Proposal, not yet coordinated]: Since a Tag in GIT is just a name for an existing sha1
commit, we can treat release tags much more elegant than with SVN where this is technically
a 'svn copy'.
  
- While doing the release candidate we give it a {projectName}-{versionNr}-rcX tag. After
all the voting passes we can now easily apply the final tag name  {projectName}-{versionNr}
to this commit since tags are just a 'name' for a given sha1 commit, and the sha1 does not
change at all when tagging. If a vote fails, we can just assign a new '-rc2', etc tag.
+ --([Proposal, not yet coordinated]: Since a Tag in GIT is just a name for an existing sha1
commit, we can treat release tags much more elegant than with SVN where this is technically
a 'svn copy'.)--
  
+ --(While doing the release candidate we give it a {projectName}-{versionNr}-rcX tag. After
all the voting passes we can now easily apply the final tag name  {projectName}-{versionNr}
to this commit since tags are just a 'name' for a given sha1 commit, and the sha1 does not
change at all when tagging. If a vote fails, we can just assign a new '-rc2', etc tag.)--
+ 
+ Do not tag a release until the vote has passed.
+ 
+ Apache does not issue release candidates in the same way that other projects do. When a
regular user sees a release candidate, they think of it as a testing version of the software.
If we tag our release artefacts (which may be prepared by anyone, at any time) as release
candidates while we vote on them, we are sending the wrong message to anyone who finds that
tag in the repository.
+ 
+ Even if we avoid calling them release candidates, all tags live in the same namespace, so
we risk confusing our users if we tag the release artefacts we are voting on, as well as the
release artefacts we have actually released. We cannot depend on deleting tags that correspond
to failed votes either, because Git does not reliably propagate tag deletion to downstream
repositories.
+ 
+ In answer to these concerns, vote emails must reference the tree-ish used to prepare the
release. Only when the vote passes must you tag that tree-ish. Preferably using the version
number alone, as each Git repository corresponds to exactly one project. The resulting tag
list in Git is a clean list of every official release, and every downstream repository will
be eventually consistent.
+ 

Mime
View raw message