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 12:45:13 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=28&rev2=29

  Be aware that the branch created by a release with GIT always covers the whole repository.
  
  === 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.
+ Please note that the __only__ officially result of an ASF release 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 ====
- Do not tag a release until the vote has passed.
+ The following is true for CouchDB which decided to ''not'' use tagging at all while voting
on a [[Release_procedure|release]]: 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.
+ CouchDB 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.
  
  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. Deleting tags that correspond to failed votes
will not help, because Git does not reliably propagate tag deletion to downstream repositories.
  
  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.
+ The Apache Maven community suggests to create a tag during the release process (mvn release:prepare)
and 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