librelist archives

Re: [pystache] Re: pull request: issue #13 (1) python 2.5

From:

Tim Kersten

Date:

2011-12-02 @ 09:35

On Fri, Dec 2, 2011 at 02:46, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
> On Thu, Dec 1, 2011 at 6:41 PM, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:
>> Thanks.  How often should we merge from the development branch back
>> into master, and what should the process be (e.g. increment the
>> version number, etc)?
>>
>> Should we do this each time we process a pull request, or less
>> frequently?  I favor doing it more frequently so we can get the
>> changes out there.
>
> I forgot to say that committing more frequently to master will also
> allow us to close issues more quickly.  I think we can close any
> associated issues after we commit to master, which will be nice..
>
> --Chris

Personally I think it's ok to close an issue if it's fixed in
development, provided we comment that it's fixed in development.
Actually, perhaps we should go for an different approach, such as
git-flow? There's pro's and con's, but I've found it to work well
with.

High level concept: http://nvie.com/posts/a-successful-git-branching-model/
A git flow helper: https://github.com/nvie/gitflow

An excellent post on why not to use git-flow:
http://scottchacon.com/2011/08/31/github-flow.html

All things considered it could be a good fit for pystache.

This would mean that HEAD of master always reflects the current stable
release, and the development branch is used only for landing new
features. When we fix a bug that we want to get out there ASAP, in
git-flow terms this would be a 'hotfix', and would be done something
like this:

Current release is 0.3.1. We have a bug fix that we want to get out
there ASAP. Create a branch called 'hotfix/0.3.2' and get the bug fix
or fixes in there, but nothing else. If we're happy that the fixes are
good, we can release this officially as 0.3.2 and push it to the
cheese shop. This would be done my merging 'hotfix/0.3.2' into both
master and development, and tagging it as 0.3.2.

The git-flow helpers above, will actually do all that for you, so it
would be something like this:

# Get started on a hotfix.
# (Branches from master, as this is the latest stable release)
# and creates the 'hotfix/0.3.2' branch.

git flow hotfix start 0.3.2

# Do bug fixes in there. i.e. commits / merge pull requests etc.
# Then, publish this to github so it can be tested/reviewed by others.
# (And bump the version number)

git flow hotfix publish 0.3.2

# When happy, release.
# This merges the hotfix into development and master, removes the local
# 'hotfix/0.3.2' branch, and makes you tag the release.

git flow hotfix finish 0.3.2

# and push master, development and the new 0.3.2 tag back to github
# and release to the cheese shop.

It would give us a clean way to quickly and safely release fixes as
soon as they're done, while at the same time landing new features for
the next feature release (i.e. 0.4.0).

Tim ^,^

On Fri, Dec 2, 2011 at 1:35 AM, Tim Kersten <tim@io41.com> wrote:
> Personally I think it's ok to close an issue if it's fixed in
> development, provided we comment that it's fixed in development.

Good point.  I agree.

> Actually, perhaps we should go for an different approach, such as
> git-flow? There's pro's and con's, but I've found it to work well
> with.
>
> High level concept: http://nvie.com/posts/a-successful-git-branching-model/
> A git flow helper: https://github.com/nvie/gitflow
>
> An excellent post on why not to use git-flow:
> http://scottchacon.com/2011/08/31/github-flow.html

Thanks for the links.  I like the idea that commits to master should
correspond to releases (both nvie and chacon).

I also like the idea of creating a new branch for each feature (again
both nvie and chacon) -- even for the small group of commits related
to an issue (e.g. branch name "issue-13").  As nvie says, together
with using the "--no-ff" flag, "this ... groups together all commits
that together added the feature."  I might disagree with this
statement of nvie, though, in our case: "Feature branches typically
exist in developer repos only, not in origin."  Chacon's post also has
feature branches existing in the origin repo.

Some of the questions I'm thinking about are the following:

How much work (adding to the cheeseshop, etc) would be involved in
creating and releasing a release (with or without git-flow)?  And
aside from the work involved, are there any disadvantages to releasing
often?  Answers to these questions will help inform (1) which issues
should be treated as hot fixes as opposed to feature branches off of a
development branch, (2) whether we need the overhead of release
branches, and (3) how often a development branch could be merged into
master.  It would be nice if we can incorporate issue resolutions into
releases often, without having them sit in a development branch for
months before being released.

Even if we decide to go with the branch structure advocated by nvie
(using a stabilizing development branch prior to merging to master),
it would be nice if it didn't require the use of a separate script.
Would it be possible for some contributors to use git-flow and others
not, or would all collaborators need to use it if we chose to go that
route?

--Chris