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 MarkStruberg
Date Sun, 20 Nov 2011 11:01:19 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 MarkStruberg:
http://wiki.apache.org/couchdb/Git_At_Apache_Guide?action=diff&rev1=27&rev2=28

  
  Be aware that the branch created by a release with GIT always covers the whole repository.
  
- ==== Release Tags with GIT ====
+ === Tagging during a VOTE ===
+ The following is true for CouchDB which decided to ''not'' use tagging at all while voting
on a release. But not normative for other projects which do treat tagging different. Please
note that the __only__ officially released ASF piece is the __source tarball__! These zipped
and signed sources are also the __only__ thing a VOTE is upon. All other artifacts produced
during a build are just nice to have goodies which are __no____ ____official____ ASF products__.
This includes the TAG on any SCM hosted at the ASF or elsewhere.
  
+ ==== Tagging policy in CouchDB ====
- --([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 most
users see a release candidate, they think of it as an officially sanctioned 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.
@@ -57, +55 @@

  
  In answer to these concerns, vote emails must only reference the tree-ish used to prepare
the release. When the vote passes must you tag the tree-ish. Preferably using the version
number alone, as each Git repository corresponds to exactly one project. The resulting tags
in Git form an accurate list of every official release, and every downstream repository will
be eventually consistent.
  
+ ==== Other possible tagging policies ====
+ The Apache Maven community contains many GIT experts and has  5 years of experience in this
area. They for example suggest to just  not push the tag immediately but only when the artifacts
will be moved  from staging to the main artifact repositories.
+ 

Mime
View raw message