Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revised branching model? #20

Closed
blaenk opened this issue Jan 7, 2012 · 2 comments
Closed

revised branching model? #20

blaenk opened this issue Jan 7, 2012 · 2 comments

Comments

@blaenk
Copy link
Contributor

blaenk commented Jan 7, 2012

I am happily surprised to see the move of your projects to github! I'm sure it'll encourage more contributions :)

However, now that we're happily on git, have you considered perhaps switching to a different branching/tagging model? Branching operations are ridiculously cheap (i.e. fast, easy, painless) on git compared to subversion as I'm sure you're aware. I think it might be nice to have some way of fetching a copy of the source that has the latest fixes applied, instead of having to wait for them until the new experimental functionality is ironed over and a new major version is released.

One method I've seen is to keep master stable while applying fixes etc. to it, and developing the next version on a separate branch such as dev. Of course this is just one way, it's really up to you. You could do it the other way around even (i.e. master is bleeding and stable is stable). My main point is that merging in patches/fixes is convenient enough that it might be possible to maintain a stable version with the latest fixes separate from experimental, perhaps yet unstable, code.

So for example, say a critical fix comes in for 0.8.9, if 0.8.9 'snapshot'/stable was the master branch, you simply merge in the fix to master and then you can merge that commit into your dev branch so that it too has the fix. Then for added benefit, you can tag the new minor version if you want.

Some references:

A nice advantage to this is that users can more or less always have a 'safe bleeding edge' by simply cloning the repo :) It might also cut down on people filing issues for things that have already been fixed but that they can't benefit from unless they track down the fix and merge it in manually. This is something I recently did with r1246 which finally did away with the sporadic crashes I was having! I wasn't even aware of that fix until I ran into it by pure chance after googling for a while. Who knows what other fixes I might be missing out on.

Again it's entirely up to you, I just figured I'd bring it up. Please don't misinterpret my comments, I am not trying to tell you how to run your own project! I'm a fan :)

@rakshasa
Copy link
Owner

rakshasa commented Jan 7, 2012

It is planned for when the next stable release is done.

@blaenk
Copy link
Contributor Author

blaenk commented Jan 7, 2012

Nice! Sounds like a perfect time to do that :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants