Post by Vadim ZeitlinSL> - Most users who just want the source code don't necessarily need to
SL> know what the development workflow is. As soon as you start tracking
SL> the `develop` branch, you know that you're going to be using fairly
SL> specific user scenarios. I'd wager that there are a lot more SOCI
SL> users than developers.
This is clearly true, although we can probably assume that only the
"advanced" users get their sources from git.
I often checkout libraries from git to try out, see if they build in
my environment,
and it's not uncommon I need to update build scripts or apply small fixes.
Having master checked out, I'm ready to submit patches back straight away.
Post by Vadim ZeitlinSL> I'm a believer in the idea that the default branch should be a stable
SL> one.
Notice that this is clearly _not_ the case when _not_ using git flow as
then all the development is done on master and stable releases branch off
it. And I do believe that most people have a clear understanding that
getting the latest master means you get the latest, but not necessarily the
most stable, version.
Yes, it seems to be like that, in default GitHub arrangements.
GitFlow overrides the role of master and if we do GitFlow, we do
master == stable.
Assuming we stick to GitFlow, I'd prefer to not to make any variations to that.
I'm not attached to GitFlow. I can drop it.
Let's propose and get all devs agree on simpler/better/preferred workflow.
Until that happens, I'd suggest with stick to GitFlow.
Post by Vadim ZeitlinSL> I'm sure there's a greasemonkey script somewhere that would allow you
SL> to automagically select `develop` rather than `master`.
This is not the only problem though. Most of the existing PRs (I was
looking over them recently trying to pick all uncontroversial ones and
apply them) were made against master and not develop too.
And I don't see this changing: when you clone a repository, it's natural to do your changes
in master. So, basically, this means that it will continue to be impossible
to merge PRs easily.
Yes, I noticed this issue too.
Post by Vadim ZeitlinAnd this is IMO a bigger problem, SOCI development is
already almost stalled and not applying PRs quickly is not going to help
get it moving faster again.
I haven't been able to find time to finally clear the 3.2.3 release
off my table.
That keeps me away from doing anything new regarding SOCI 4.
My experience with maintaining and releasing SOCI bugfix releases
revealed that one PITAs is
1. Collecting all PRs that qualify for a bugfix release
- often fixes submitted in big PR bundles need to be cherry picked
- often fixes submitted against develop need to be ported to master
- often fixes do not receive any feedback or review, so unclear they are good
- maintenance is no fun, but a time consuming boring task :)
Post by Vadim ZeitlinIn fact, my personal favourite solution would be to keep master the
default branch but drop git flow entirely.
That's a clear & fair request. As I mentioned above, I'm not attached.
Post by Vadim ZeitlinIt's probably a good workflow
for managing a team of many developers and a project with many releases,
but neither of these criteria applies to SOCI: there are few developers and
even fewer releases. Using the traditional master-and-release-branches
workflow is simpler and would IMHO be quite enough for this project.
I chose GitFlow because it is well structured workflow that makes it
no-brainer yet simple to follow, with one caveat...once you learn it :)
Post by Vadim ZeitlinOf course, this wouldn't help with your concerns as master would be
exactly as [un]stable as develop is now. But if this helped SOCI
development it would be still well worth it IMO.
Ok, let's make it happen, unless there are objections from other
developers and contributors.
To make it clearer what we are going to decide between, quick summary:
1. On one hand, we have GitFlow -
http://nvie.com/posts/a-successful-git-branching-model/
a well structured workflow that proved to be not as well known as I'd
assumed and too detailed for SOCI.
2. On the other hand, we have, so called, GitHub flow -
http://scottchacon.com/2011/08/31/github-flow.html
a kind of rolling release workflow, where master is always deployable
aka stable (as in GitFlow)
3. Somewhere in between, we have traditional workflow known from, for
example, Subversion:
- master - here all development happens (submitted and merged from
*topic* branches!)
- release/X.Y.Z - maintenance branch
- tags/X.Y.Z - tag
It seems, git makes release/X.Y.Z redundant, because if hotfix
arrives, we can always create a branch
from the tag, then release and tag with new version (along with
merging into master, of course).
Now, the option 1. proved to be too complicated for us.
The option 2, to me personally, sounds compelling as it seems to
remove most of the maintenance and
releasing hassle - a PR arrives, it's reviewed and tested, then either
refused or merged to master.
If merged, it's released - the master is a release. But, are we happy
with no-version release?
The option 3 has the advantage of structure, is well known traditional
workflow and has versioned releases.
My vote:
1. Drop GitFlow: +1
2. New workflow: +1 for either 2 or 3
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net