SwarmRobots have multiplied - in need of naming, version and licence help!

[spanner888]

We now have three different SwarmRobot hardware versions in development (more coming?) plus we have several older versions of the PCB and breadboard prototypes.

There are also now three different shields (and many more to make!) and the different code to support the different SwarmBots and shields PLUS all of the different versions of each hardware and software item.

So we need some structure to help manage all of this!   So please review and tear apart and comment on the suggestions below :).

Suggestions, based on the current work for the SwarmRobot process and motor controller PCB:

SwarmRobot-Tiny
SwarmRobot-Uno    (is the motor controller on the shield?)
SwarmRobot-Sunny

For the shields we also need to indicate which Swarm robot they fit, so I suggest:

SwarmRobot-Tiny-Shield-IR-Rx
SwarmRobot-Tiny-Shield-WallFollow-Avoid
SwarmRobot-Uno-Shield-Motor-IR-RxTx
etc

Then the code should follow similar convention to indicate which hardware is supported.

To manage the code should we create git branches for each variation? Then the other branches can choose what to merge (or can only the main branch do that?).  I have added some basic git info at the end of this email.

How does SwarmBot instead of SwarmRobot fit, or should we keep these names shorter and just use SR, or XCJ-SR.....?


For version numbering, I propose we start/continue v0.0x, then when getting near a "polished" first version move to 0.x, then 1.x on first release (eg for the Afron competition).

Finally - does anyone know what software and hardware licences Xinchejian prefers to use?

The wiki says ""

Can't find anything in Xinchejian GIT.

Any suggestions?

--------------------------------------------------------------------------------------------------------
Here is some Git how to information from git - the simple guide

"Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion."

create a new branch named "feature_x" and switch to it using
    git checkout -b feature_x
switch back to master
    git checkout master
and delete the branch again
    git branch -d feature_x
a branch is not available to others unless you push the branch to your remote repository
    git push origin <branch>

update & merge

to update your local repository to the newest commit, execute
    git pull
in your working directory to fetch and merge remote changes.
to merge another branch into your active branch (e.g. master), use
    git merge <branch>
in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
    git add <filename>
before merging changes, you can also preview them by using
    git diff <source_branch> <target_branch>

[Paul Adams]

for the git thing, just add in a blank page or copy / paste from
xinchejian wiki

On Fri Aug 31 11:22:39 2012, spanner888 wrote:
> We now have *three different SwarmRobot hardware versions* in

> development (more coming?) plus we have several older versions of the
> PCB and breadboard prototypes.
>

> There are also now *three different shields* (and many more to make!)
> and the *different code to support the different SwarmBots and
> shields* PLUS all of the *different versions of each hardware and
> software item*.

>
> So we need some structure to help manage all of this! So please
> review and tear apart and comment on the suggestions below :).
>
> Suggestions, based on the current work for the SwarmRobot process and
> motor controller PCB:
>
> SwarmRobot-Tiny
> SwarmRobot-Uno (is the motor controller on the shield?)
> SwarmRobot-Sunny
>
> For the shields we also need to indicate which Swarm robot they fit,
> so I suggest:
>
> SwarmRobot-Tiny-Shield-IR-Rx
> SwarmRobot-Tiny-Shield-WallFollow-Avoid
> SwarmRobot-Uno-Shield-Motor-IR-RxTx
> etc
>
> Then the code should follow similar convention to indicate which
> hardware is supported.
>

> *To manage the code should we create git branches for each variation?*

> Then the other branches can choose what to merge (or can only the main
> branch do that?). I have added some basic git info at the end of this
> email.
>
> How does SwarmBot instead of SwarmRobot fit, or should we keep these
> names shorter and just use SR, or XCJ-SR.....?
>
>
> For version numbering, I propose we start/continue v0.0x, then when
> getting near a "polished" first version move to 0.x, then 1.x on first
> release (eg for the Afron competition).
>

> Finally - does anyone know what *software and hardware licences*

> Xinchejian prefers to use?
>
> The wiki says ""
>
> Can't find anything in Xinchejian GIT.
>
> Any suggestions?
>
>
>
> --------------------------------------------------------------------------------------------------------
> Here is some Git how to information from git - the simple guide

> <http://rogerdudler.github.com/git-guide/>

>
> "Branches are used to develop features isolated from each other. The
> master branch is the "default" branch when you create a repository.
> Use other branches for development and merge them back to the master
> branch upon completion."
>
> create a new branch named "feature_x" and switch to it using
> | git checkout -b feature_x|
> switch back to master
> | git checkout master|
> and delete the branch again
> | git branch -d feature_x|

> a branch is /not available to others/ unless you push the branch

> to your remote repository
> | git push origin <branch>|
> ||
> ||
>
>
> update & merge
>
> to update your local repository to the newest commit, execute
> | git pull|

> in your working directory to /fetch/ and /merge/ remote changes.

> to merge another branch into your active branch (e.g. master), use
> | git merge <branch>|
> in both cases git tries to auto-merge changes. Unfortunately, this

> is not always possible and results in /conflicts/. You are
> responsible to merge those /conflicts/ manually by editing the

[spanner888]

On 31/08/12 11:22, spanner888 wrote:

oops - The wiki says "Content is available under Creative Commons Attribution Non-Commercial Share Alike." - I think the intent is good for software, but that is not really a software licence.

Plus we should also specify the hardware licence - suggestions please!

[Paul Adams]

its great for documentation, hardware, but not software. GPL3 if you
dont want anyone to keep it closed, hidden away, or BSD license
meaning.. do what you like, it doesn't matter, even commercialize it and
keep it locked away.

attribution, non-commercial, share-alike

again since all the accounts are tracked automatically in git/wiki then
it isnt a problem to change the license later after contacting people
working on it.

Paul

On 8/31/12 11:29 AM, spanner888 wrote:
> On 31/08/12 11:22, spanner888 wrote:
>> oops - The wiki says "Content is available under Creative Commons
>> Attribution Non-Commercial Share Alike

>> <http://creativecommons.org/licenses/by-nc-sa/3.0/>." - I think the