Clawpack moving to Github

4 views
Skip to first unread message

Randall J. LeVeque

unread,
May 9, 2011, 3:17:17 PM5/9/11
to Developers of Clawpack
Soon I plan to release Clawpack 4.6.1 with some recent enhancements
that are in the 4.6.x branch. Let me know if there's more to add or
things that appear broken.

At that point I will also create a repository on the Github Clawpack
site named clawpack-4.6.x
and plan to do any further development of this branch using Git and
Github rather than Subversion and kingkong.

I'm also working on some documentation for developers, with the
suggested workflow for using Git and Github.

Meanwhile we will start developing Clawpack 5.x in the other
repositories on Github. Some information about the planned changes
can be found at https://github.com/clawpack/doc/wiki.

- Randy

David Ketcheson

unread,
May 10, 2011, 9:44:46 AM5/10/11
to claw-dev
On May 9, 10:17 pm, "Randall J. LeVeque" <r...@uw.edu> wrote:
> I'm also working on some documentation for developers, with the
> suggested workflow for using Git and Github.

FYI, for PyClaw we've started following this model:

http://nvie.com/posts/a-successful-git-branching-model/

-David

Randall J. LeVeque

unread,
May 10, 2011, 11:52:00 AM5/10/11
to claw...@googlegroups.com
Thanks for this link David, it appears to be a very good model to follow.

With this model, what we now call the trunk in the Clawpack Subversion
repository would be the master branch, corresponding to the current
release. Our current branches/4.6.x would be replaced by the Git
branch "develop", with the version number chosen only when it's
branched to release-4.6.2 or release-4.7 or whatever, which seems a
more sensible way. (For example we decided to release what was in the
4.5.x branch as 4.6.0, which was a bit confusing.)

I'd suggest Clawpack developers read through this carefully (after
reading some tutorials on Git, or it won't make sense) and we'll try
to follow this model.

There's also a 1-page summary of this post that appears in a comment
below it by ewheeler that will be a useful reference,
http://www.globallinuxsecurity.pro/static/git/cheetsheet.pdf

- Randy

> --
> You received this message because you are subscribed to the Google Groups "claw-dev" group.
> To post to this group, send email to claw...@googlegroups.com.
> To unsubscribe from this group, send email to claw-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/claw-dev?hl=en.
>
>

David Ketcheson

unread,
May 11, 2011, 9:37:06 AM5/11/11
to claw-dev
In the last couple of days, a few people have suggested to me that it
would be easier to modify this workflow by making 'master' the
development branch and having branches for releases. Based on my
experience so far, I think this is a good idea, because most of the
time we will be working on the development branch, so it's much more
convenient if that is the branch that you get by default.

That way, 4.6.x would become 'master' and then release branches would
be created for things like 4.6.2, 4.7, etc.

Opinions?

-David

Aron Ahmadia

unread,
May 11, 2011, 10:02:53 AM5/11/11
to claw...@googlegroups.com
+1 to master as development branch

This will also encourage the developers to verify against unit tests before breaking development

A

Randall J. LeVeque

unread,
May 12, 2011, 1:39:09 AM5/12/11
to claw...@googlegroups.com
This seems like a sensible plan. I guess the idea of having 'master'
be the latest version is that people who clone it will have an
official release (as with our previous 'trunk'), but as long as we are
tagging the releases, it does seem simpler for developers to have
'master' be the main development branch. Most ordinary users will get
a tar file rather than cloning it anyway I suspect.

- Randy

Reply all
Reply to author
Forward
0 new messages