So now that the SVN may rest in peace, how about to make life simple, everybody will use the git flow diagram (either they use master or develop, either they are advanced developers or simple folks) - it would make life easier if everybody work along the same guidelines.

It is something like: whatever you do, clone and checkout a branch (develop or master), if you want to add your own code, just follow the diagram. If you just work on your own code, doesn't matter - just start a feature and commit locally (or publish and push once in a while if you like a backup)

On Fri, Apr 19, 2013 at 3:36 PM, Daniel Russel <drussel@gmail.com> wrote:

On Apr 19, 2013, at 2:06 PM, Yannick Spill <yannick@salilab.org> wrote:

> Le 19/04/13 20:18, Daniel Russel a écrit :
>> On Apr 19, 2013, at 10:35 AM, Ben Webb <ben@salilab.org> wrote:
>>
>>> On 4/19/13 10:29 AM, Daniel Russel wrote:
>>>> The only issue that is in the release milestone relates to the web pages.
>>> I would prefer to let the nightly build run first to make sure no horrible problems have cropped up, then update master from that revision. Otherwise it would seem that the release hasn't even been tested to compile everywhere, which is less testing than the nightly builds themselves.
>> Sure. I practice, I think that and what I am suggesting are identical (in that we will continue to patch the release and there will be plenty of lag between declaring a version the release and getting everything ready for people to take).
>>
> If by release you mean a release branch (see first figure of http://nvie.com/posts/a-successful-git-branching-model/), which implies to freeze functionality and only correct warnings and bugs, I agree. There are still warnings in the isd module so I would like to get rid of them before we commit everything to master.

The original plan, from what I recall, had been to release today, but we can slip a bit :-) I don't see much reason to wait for things like warning suppressions are quite reasonable to patch into the master afterwards anyway and there are an infinite number of such changes that we want to make.

>
> Just to be sure: we *are* following the git-flow model as described in this link, are we? With feature branches, release, hotfix, and develop and master, right?

At least for feature branches. I haven't end up using git flow release for the release so far because it didn't play well with having an svn repository and, since we are feeling things out a bit, I wanted to get a reasonable IMP state into the master branch sooner rather than at the end. I don't have much experience with hotfixes yet, so we shall see about those. They require that you specify the version manually, which is a bit annoying, but being able to search by tags for point release versions might be nice.

_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev

--
Barak