Peter Morgan wrote:
>>
>>> Best give I can give is to have the branches
>>> - master = the latest stable release
>>> - next = the next version and unstable
>>
>>
> One of the challenges with git is that is flexible and allows for many
> work flows. There isn't one "right way", but there are some common
> workflows.
>
> The most common workflow that I have seen is as follows:
> * most or all development happens on the master branch
> * each new feature gets it's own branch, which is merged or rebased with
> the master branch when it's mostly complete and doesn't break the build.
> * releases are cut as tags from master or from a version branch or stable
> branch(i.e. potential branches: master, stable, 1.2.x, 1.3.x, tags: 1.2.1,
> 1.2.2, 1.3.1)
>
Yes indeed, we need to create the tags.. I should have mentioned that..
>
> My advice is somewhat contrary to Peter's:
> * branches are awesome, use them whenever developing a new feature. Local
> branches can easily be discarded if things don't work out. Use public
> branches in the git repo with some reservation,
> * You should use a new feature branch for each new feature in your local
> repo. Once the feature is ready for merging, then merge/rebase and push the
> changes to github.
> * Using a branch allows for you to easily switch between various
> works-in-progress.
>
Well, can I add, cos I 100% agree, there's ways of slkinning a cat/penguin
with git, particular in Sweden/Finland ..;-)
So the thought in my head is what "distributors" will use, eg the latest
ubuntu..deb or win.zip, installers..
I would assume that they would want master to be the "stable"
ie tag-1.3. == latest-stable == master
If changes are pushed to master in - which is what we all want as dev's,
the the distributors will be rebuilding every day...
This dilemma I know is from the flightgear.org, the flightsim project..
which is why that thought is very much in my mind..
the issue there with master vs tag vs dev is huge..
so at least all the devs know that next is fun and not dangerous.. kinda..
>
> Peter's next+master workflow is what the Linux kernel uses. It kind of
> mirrors master+stable branches in other projects.
>
> didnt know that.. but it does that use odd for dev and even for release ..
is that a numbering schema.. ?
> One alternative workflow is called git-flow, which is outlined here:
> http://nvie.com/posts/a-**successful-git-branching-**model/<http://nvie.com/posts/a-successful-git-branching-model/>
>
> One of the best ways to develop is using a continuous integration model.
> In this model, each commit to "master" is compiled and run against a series
> of tests, to determine if the project is viable.
>
> Travis CI offers free continuous compiling/integration for open source
> projects. It even integrates with github:
> https://travis-ci.org/
>
> Whaw Jason.. snap.. ;-)
The travis job is here..im my branch atmo
And there is no make test...
But indeed we can build against it certainly..
means dimitri can now with an ipad, do a marge and make a tag and release..
from somewhere on something..
=== versioning ==
About revision Nos''
The problem is that the "current version" is hidden way in config..
What would be really helpful is to have a file "./version"
with the release eg 7.8.9
This means that a remote system can directly check that "file" and deal
with things..
Looking here at making release automatic builds..
ie a debian package, or windows install with nsis etc
== Travis ==
Have the travis kinda working of "daffodil" which is my github fork..
https://github.com/daffodil/doxygen
the config is here
https://github.com/daffodil/doxygen/blob/master/.travis.yml
Problem
To make travis work as a link..
The README is now a README.md with markdown
This is richer and better.....
Merge request is here
https://github.com/doxygen/doxygen/pull/1
Travis is real cool cos the binaries can be built there..
Anyway.. this is fun..
ALSO
===============
BUGS
===============
I'll be frank, I hate bugzilla, its a pain to even want to find a bug..
So can we enable the Issues in GitHub please, and the lovely thing for
github is it integrates well..
There's a scipt and stuff here..
So need to bind the bugs to the source which is what git hub does well, eg
match bug against patch
http://stackoverflow.com/questions/7281304/migrate-bugzilla-issues-to-github-issue-tracker
regards
pete
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Doxygen-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
