Delete ArduCopter version branches in favor of tags

[magicrub]

delete copter specific version branches in favor of using tags which plane, tracker, and rover already use.
ArduCopter-2.8.1
ArduCopter-2.9
ArduCopter-3.0
ArduCopter-3.1
ArduCopter-3.1.1
ArduCopter-3.1.2
ArduCopter-3.2
ArduCopter-3.2.1
Copter-3.3
Copter-3.3-pixracer
Copter-3.4

We'll want to replace that with a new branch called ArduCopter-release

[billbonney]

You have an option to create an 'Archive' repository. i.e. one that that is clone of ardupilot called ardupilot/ardupilot-archive and then delete the branches from the main repo. This at least keeps place to keep the history, and for developers with projects based on these older variants to find. Please don't delete them unless they have been copied and kept safe elsewhere.

You may still need to create new release branches, e.g copter-3.4.1 etc, even if you have a main 'copter-release' branch. If you need to patch a release and you want that to be minimal it is the only way.

In summary, the solution is to archive branches (and tags ;) ) to cloned repo and then delete them from the main development repo.

NOTE: I'm not sure what happens to a tag of a commit that only belongs to a branch that is deleted? Would be worth cloning the repo and doing some tests.
Updated: If you delete a tag branch, the branch remains, but only easily accessible by the tag name, you can then create a new branch as required.

Another thought to note, if you create and archive repo, you can remove branches and history from the main repo to save size. Ardupilot is only 125MB so its not large, and it doesn't have lots of graphical type assests so projected growth is slow. (info here on handling large repos http://blogs.atlassian.com/2014/05/handle-big-repositories-git/ )

[OXINARF]

I don't think another repository is a good idea. As @billbonney has experienced a tag is very similar to a branch, so deleting the branch leaves it there if it has a tag.
I like to have few branches so I like the idea of having tags instead of branches but I'm preparing a document with a few rules for releases and that includes what to do in GitHub, so I'd like to wait before going ahead with this.

[magicrub]

Bill, these are all tagged so deleting the branch won't lose anything.

On Nov 9, 2016 7:21 AM, "Francisco Ferreira" notifications@github.com
wrote:

I don't think another repository is a good idea. As @billbonney
https://github.com/billbonney has experienced a tag is very similar to a
branch, so deleting the branch leaves it there if it has a tag.
I like to have few branches so I like the idea of having tags instead of
branches but I'm preparing a document with a few rules for releases and
that includes what to do in GitHub, so I'd like to wait before going ahead
with this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5176 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEj7GwZVrghXIRg1sUVWkfhuKdWwmjOlks5q8eTngaJpZM4KtNBB
.

[billbonney]

As @billbonney has experienced a tag is very similar to a branch

So name pollution in the tag space is ok, but in the branch space it's not. I don't see the difference. I'm also not that bothered by the branches. we can create new branches and just move on.

It does impact the work flow not having branches, since if i create a fix to a release (which would require checking out a commit, make it a branch in my fork and then try and submit a PR to upstream, I can't as the PR cannot be raised against a TAG (even though the text in the entry box seems to indicate you can, you can't)

I think having a separate archive repo for the old branches and just keep the new main repo is an interesting idea. you can remove the old branches/tags (and history) reducing the repo size. But I'm not advocating that happen. it was just a solution to what @magicrub proposed.

[magicrub]

branches for PR's need to merge with master without conflicts, ideally they were recently rebased onto current master. It's silly to consider a PR based on copter v3.1.2 tag or branch.

[OXINARF]

So name pollution in the tag space is ok, but in the branch space it's not. I don't see the difference.

Tags are more hidden in GitHub and almost all Git UIs. Having it as tags removes more distraction.

It does impact the work flow not having branches, since if i create a fix to a release (which would require checking out a commit, make it a branch in my fork and then try and submit a PR to upstream, I can't as the PR cannot be raised against a TAG (even though the text in the entry box seems to indicate you can, you can't)

I agree that can be a problem, although it's not too common to see PRs for old versions (the latest version would always have a branch). We can have the two latest versions, I don't see we have the resources to be supporting more than that.

I think having a separate archive repo for the old branches and just keep the new main repo is an interesting idea.

In my opinion that just causes more confusion and it increases maintenance work.

branches for PR's need to merge with master without conflicts

If it is a fix for an older version it may not apply to master at all.

[Naterater]

Do we still want to do this or has this been done yet?

[OXINARF]

We still want this.

[rmackay9]

I might close this if that's OK. I like the current method of using version specific release branches. Rover, Plane and even Tracker have adopted the Copter method now as well.