-
-
Notifications
You must be signed in to change notification settings - Fork 420
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
Comments
It is planned for when the next stable release is done. |
Nice! Sounds like a perfect time to do that :) |
Open
This was referenced Sep 3, 2014
ss23
pushed a commit
to ss23/rtorrent
that referenced
this issue
May 21, 2018
ss23
pushed a commit
to ss23/rtorrent
that referenced
this issue
May 21, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 asdev
. 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 andstable
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 tomaster
and then you can merge that commit into yourdev
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 :)
The text was updated successfully, but these errors were encountered: