Published Git tags are *not* movable (by design). You're better off making it a 
branch that you treat like a tag, if that's your desire. Even then, you might 
confuse someone who is less familiar with Git in some cases if you move that 
branch around.


> On Jun 26, 2014, at 6:06 AM, "Jeff Squyres (jsquyres)" <> 
> wrote:
> I've thought about this a little, and I'm still inclined to use the 
> simple/lazy method of tags on master.  Some random points, in no particular 
> order:
> 1. master should always be for development, IMHO.  If we start using a 
> multi-branch scheme, then the branches should be for releases, etc.
> 2. MTT has always been distributed by VCS; we've never made discrete 
> distributions (e.g., a tarball).  As such, I'm comfortable labeling it as a 
> bit "different" than how most other software is delivered -- e.g., using git 
> tags on master is "good enough".
> 3. The level/frequency of MTT development is fairly low; it would be good to 
> keep the bar as low as possible for amount of work required to deploy a new 
> feature to the OMPI community for MTT testing.  Meaning: a new feature or bug 
> fix pops up in MTT every once in a while -- we generally don't have commits 
> that are being developed and merged to a release series in an out-of-order 
> fashion.  So doing a few commits for a new feature/bug fix and then tagging 
> the result is fine/good enough.  If there *are* interleaved commits of 
> multiple new features/bug fixes, we can simply wait until all are done before 
> tagging.
> 4. I realize this scheme is not as flexible as a release branch (where you 
> can merge new features/bug fixes out of order), but the level of MTT 
> development is so low that I'd prefer the slightly-simpler model of just 
> tagging (vs. merging/etc.).
> 5. I'm not sure how using a release branch is less error-prone...?  I 
> understand git branching is cheap, but if we have a separate branch, then we 
> either need to remember to cherry-pick every commit we want or we have to 
> continually merge from master->release_branch.  Seems like more work/steps to 
> follow, and therefore more error-prone.
> 6. The point about not being able to automate getting the latest stable MTT 
> is a good one.  How about using numerical tags just to delineate our intended 
> "release" points, but also have a moveable tag, e.g., "ompi-mtt-testing" that 
> will always point to the latest "release" that we want the OMPI MTT test 
> community to use?  That way, you can always "git checkout ompi-mtt-testing" 
> to get the latest/greatest.
> ( that end, I've created/pushed an ompi-mtt-testing tag and pointed to 
> the same place as v3.0.0)
>> On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet 
>> <> wrote:
>> +1 for using branches : branch usage is less error prone plus git makes
>> branching unexpensive.
>> as far as i am concerned, i'd rather have the default master branch is
>> the for the "stable" version
>> and have one branch called devel (or dev, or whatever) :
>> - git clone => get the stable (aka master) branch by default (safe by
>> default)
>> - if you use the devel branch, one can only assume you know what you are
>> doing ...
>> That being said, tags on the master branch is a good practice
>> Cheers,
>> Gilles
>>> On 2014/06/25 2:33, Christoph Niethammer wrote:
>>> As an alternative idea: What about using branches to mark "stable" and 
>>> "development"?
>>> Tags are for fixed versions and so users will not receive updates unless 
>>> they update their update scripts manually?!
>>> When "development" is stable just merge into "stable".
>> _______________________________________________
>> mtt-devel mailing list
>> Subscription:
>> Link to this post: 
> -- 
> Jeff Squyres
> For corporate legal information go to: 
> _______________________________________________
> mtt-devel mailing list
> Subscription:
> Link to this post: 

Reply via email to