Comments (3)
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.
from django-address.
@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 thedev
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.
from django-address.
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.
from django-address.
Related Issues (20)
- Add end-to-end tests
- Use Docker for example site HOT 2
- Admin does not query google HOT 2
- default Autofield and django 3.2
- Update translation to Django 4 HOT 1
- Nonexistent parent node ('address', '004_auto_20220227_1259') HOT 16
- Include serializers for usage inside rest framework HOT 2
- Error installing version 0.2.7 due to incorrect metadata HOT 1
- Python3.9 integration HOT 2
- Address save via admin saves the primary key into raw column, and additionally creates a bare new object HOT 3
- unique=True HOT 2
- Error when using together with Django autocomplete fields in admin HOT 3
- {{ form.media }} seems to render nothing in Django 4 HOT 2
- Address Form field only populates if full address is provided.
- Fill related models upon Address creation.
- Support for model serializer with django-rest-framework HOT 4
- Add documentation to readthedocs
- Prefer django_countries.fields.CountryField instead of implement address.models.Country
- AddressField on admin site
- Cant select address without `address_street_number`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-address.