Split the dev branch into separate repository?

[furious-luke]

Due to the development branch having a very different data schema and access methods, I've been intending on splitting the repository into something like django-address2. The reasoning behind this is to ensure anyone who is happy using the current master branch doesn't suddenly have their code break during an upgrade, and can continue to receive bug fixes for the old system.

I'm not 100% sold on this plan, and would be equally happy to continue the same repository so long as users are happy to do a little work when the development branch finally gets merged. Maybe users with an opinion on the matter could comment?

Thanks!

[jplehmann]

Hi @furious-luke, it's been a year almost since this issue but none have left feedback. As one of the users of the dev branch, I am very interested in seeing this issue get moved forward in one way or the other. It seems for this work to remain as a branch and in "limbo" is the worst of all 3 possible outcomes.

I think that merging dev back into master would be more work up front, but assuming it's a superior design, will pay dividends by not breaking up our small user base. The more versions we have, the more spread thin the contributors will be. And seeing that you have not been too active on the project, for this project to thrive we need more users and contributors all united in one version. I was encouraged to see @pydanny and others creating issues and some PRs over the last year, and would love to unit the efforts.

I know this is easier said than done, and I don't know the actual differences between the two branches.

[jplehmann]

@furious-luke I know you are not so involved these days, but I was hoping you could chime in on this issue to give us advice on going forward.

I am assuming that we are probably the only ones actually using the dev branch, so it doesn't seem to make much sense from a maintenance point of view to break this into a new project. That leaves us with merging it back into master or abandoning it being the two options. Based on your previous feedback I am guessing merging it is not a feasible plan.

Therefore could you help us understand what it would look like for us to migrate ourselves from dev back into master? I am honestly not sure that we ever needed to be on the dev branch in the first place. We do care about international addressing, but we only need support at the city level and up, not at granularity of street address. For that matter our use cases might be simpler such that other libraries would suffice.

Here are some past comments Luke made to me privately which might be helpful to this conversation of what dev branch is about.

I've been working recently on improving the overall structure of django-address, especially with regard to handling obscure international addresses. At the moment there are a few issues with various nations, even the U.K. has some addresses that don't fit in to the categories I'm currently using. The new system will dynamically create address component hierarchies to match whatever Google gives back from the geolocation request. So, my suggestion is, if you can wait for another week (maybe two), I should be able to push out this update and it will, I think, make international address handling much easier.

And later:

Yeah, it's tough to know the right course of action for django-address. At the moment I'm thinking I need to leave the master branch as is. I happened to meet another user of the package at PyCon in Melbourne recently and they're satisfied with the master branch the way it is. They feel the dev branch is too complicated for their usecase.

Having said that, I'm interested in figuring out a better way of managing international addressing. The dev branch is okay, but I think it can be done better. I'm still in the process of thinking about a more complete strategy, but am interested to hear your thoughts on it.

[banagale]

Since I've begun addressing this concern here, I'm going to close this issue for now.

My hope is that we can find a way to help you get migrated, or at least the new architecture on master has a reasonable migration path you could implement.