Skip to content
This repository has been archived by the owner on Oct 18, 2021. It is now read-only.

Changing name of default branch? #142

Closed
saghm opened this issue Apr 4, 2016 · 9 comments
Closed

Changing name of default branch? #142

saghm opened this issue Apr 4, 2016 · 9 comments
Assignees

Comments

@saghm
Copy link
Contributor

saghm commented Apr 4, 2016

Right now, the default branch is called 1.0. This made sense when we were first writing the driver, since we were writing a new driver for Rust 1.0 as opposed to the earlier version for pre-stable Rust. However, Rust stable is now at 1.7 (and will continue updating with new minor versions every six weeks), so I'm thinking it might be more idiomatic to name it something that would be more version-agnostic (with respect to Rust). I don't have any strong opinion on what that new name should be, but given that master is basically defunct now and we probably aren't going to want to deal with merging 1.0 with it or anything like that, I'm thinking current or something along the lines of that might make more sense.

@vkarpov15 @kyeah any thoughts?

@saghm
Copy link
Contributor Author

saghm commented Nov 13, 2016

@kyeah I just wanted to bump this issue again in light of #170. "1.0" doesn't actually refer to anything useful anymore; it originally meant that we were developing for Rust 1.0 rather than 0.x like the previous implementation of the driver was, but given that Rust is now on 1.13 (and has proven to be pretty stable in terms of releases, as we've never had to make any fixes due to language changes), I think that it would be worth changing to something more generic (especially since "1.0" might imply to some people that this is version 1.0 of the driver, which is definitely not the case)

@kyeah
Copy link
Contributor

kyeah commented Nov 19, 2016

I think we need an admin to turn on the travis switch for 1.0, but yeah, moving to master (and moving master to legacy or something) would be fantastic. I'm going to look into doing just that.

@kyeah kyeah self-assigned this Nov 19, 2016
@kyeah
Copy link
Contributor

kyeah commented Nov 19, 2016

@saghm don't know how you feel about doing a simple name swap and -f push -- generally this is an awful, sketchy idea, but since everyone has been working with 1.0 for over a year and nobody should be dealing with the Rust 0.7 driver on master, I think this is the best option here for future peace of mind.

$ git checkout 1.0
$ git branch -m master legacy  # move master to legacy
$ git branch -m 1.0 master     # move 1.0 to master
$ git push origin legacy       # push legacy
$ git push -f origin master    # push master

$ git push origin :1.0         # delete remote branch 1.0

@saghm
Copy link
Contributor Author

saghm commented Nov 20, 2016

I can take care of talking to the powers that be to switch the default branch once we make the change.

As for the process of the actual branch changes in git, do you think it's better to completely delete 1.0 (i.e. renaming it to master) or to just checkout master from 1.0 and switch to developing there? The former would be useful in that anyone remotely tracking 1.0 would notice the change in default branch the next time they tried to pull, but it would mess with the history and likely force people to have to clone a fresh copy of the repo, which could be a hassle for anyone maintaining a fork for their own use. (Renaming the current master branch to legacy will obviously also mess with the history, but nobody should be using this branch anymore, so that isn't a problem.)

On the other hand, checking out a new master branch from 1.0 (after renaming the old one) ensures that the history doesn't get messed up, so nobody will have to do anything complicated to fix their forks, at the cost of the history looking slightly more convoluted and the possibility that people tracking 1.0 won't notice the change unless they actively look for it.

@kyeah
Copy link
Contributor

kyeah commented Nov 20, 2016

We should go with renaming 1.0 (deleting it) instead of checking out master from it. Anyone working on top of 1.0 should have their own branch/fork, and will be able to pull from/open a PR against master since it'll have the same commit history. We'll be continuing work on master, so they'll have to do this anyways once their fork falls behind in commits -- better to make it clear that 1.0 is obsolete, perhaps with a temporary README disclaimer.

@saghm
Copy link
Contributor Author

saghm commented Nov 20, 2016

Cool, sounds good. I assume that you don't have any objections to me taking care of this now?

@kyeah
Copy link
Contributor

kyeah commented Nov 20, 2016

Nope, go for it.

@saghm
Copy link
Contributor Author

saghm commented Nov 20, 2016

I'm going to hold off on deleting 1.0 for now just in case Github does something weird if you delete the default branch

@saghm
Copy link
Contributor Author

saghm commented Nov 28, 2016

The default branch has been changed to master and 1.0 has been deleted

@saghm saghm closed this as completed Nov 28, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants