Allright, I'm ok with "Github-flow" : master is trunk/develop, ie the "current" state. (Btw, "Github flow", "Git Blow", "Git Flow"... wtf ??? come on !!!)
Btw, instead of having the version 1.7.0-SNAPSHOT, it's usually better to have a "latest" version on that branch. I mean, you don't really know if next version will be 1.7.0-SNAPSHOT : it's just the "next release". So instead of 1.7.0-SNAPSHOT, I would use LATEST-SNAPSHOT on master. Then when creating the release branch, we set the appropriate version. Now for bugs. Let's say a bug arrives on 1.6.0. I guess we fix them on the release branch and try to merge this on master ? Cheers Rémi 2015-08-02 15:45 GMT+02:00 Rick Grashel <[email protected]>: > Hi Remi, > > IMHO, the Github front page needs to better explain what's going on and > what is expected from a dev standpoint. I'll see if I can put something up > there to call things out. Especially if people aren't familiar with or > confused by Github projects or Github. > > The branching and commit model is Github-flow. ( > https://guides.github.com/introduction/flow/). Basically, a single > master that has to be buildable and deployable at all times. This > represents the next release. Developers create their own branches for > things they want to work on. If a developer has something they want to > contribute back, they can create a pull request for whatever they are > working on and then it can be discussed. Ultimately, pull requests are > merged into master once they are deemed ready. When we release a version, > we create a release branch from master, update the Jenkins builds, and > publish to the Maven repos. It's pretty lightweight (I think far more so > than Git-blow) and simple to use and maintain. It also integrates > extremely well with Maven automation when it comes to branching and > releasing. There is also good cross-platform and command-tooling that > supports Github-flow. > > I'll try to get something more descriptive on the project page this week, > but I can't see us changing this right now. If we had a ton of traffic and > movement and it was warranted, Git-flow would probably be something we > could look at. > > -- Rick > > > On Sun, Aug 2, 2015 at 4:32 AM, VANKEISBELCK Remi <[email protected]> wrote: > >> Hi folks, >> >> Just had a peek at the repo, and didn't really understand the branches in >> there. >> >> Is master supposed to be the "trunk" (or "develop") ? >> The "version" branches are release branches ? >> ... >> >> I suggest we follow the Git Flow conventions : >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> It's a branching model that IMHO works fine in small-medium projects. It >> is commonly used and therefore easy to understand, by convention. >> >> The idea is to have a "develop" branch (LATEST-SNAPSHOT) to be used for >> "day to day" development (and feature branches if you want), and a "master" >> branch for releases (and release branches). >> >> You can install the Git Flow command line tooling for easy management of >> all this. It's really a useful layer over git IMO. >> >> What do you think ? >> >> Cheers >> >> Remi >> >> PS : I'm taking 1.6.0 out for a spin, trying to see if I can upgrade in >> Woko... I use loads of extensions so I guess it's a good test. Will let you >> know. >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Stripes-development mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/stripes-development >> >> >
------------------------------------------------------------------------------
_______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
