Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub
Brought to you by:
dimitri
Menu
▾
▴
Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub
|
From: Peter M. <ped...@gm...> - 2013-05-21 01:59:32
|
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 |
