As I've been looking at things trying to get them wrapped up for a release, one of the dependencies that is a bit of a challenge to manage is django-registration. We're stuck in limbo where we should probably convert to using the latest version but it hasn't been officially released yet. There are probably a few patches I would like to provide so that it is a little more compatible with the latest django versions.
My question for this group is, how are you typically integrating Satchmo into your other django sites? Is Django registration common enough that if we tried to maintain our own fork, that you would be put at a disadvantage? In general, I like having the benefits of using other packages but sometimes we get too tightly restricted to another release cycle. Also, registration is fairly mature and not going to drastically change in the future. >From the way I see it, there are 4 options: 1. Stay the way we are and convert when 0.8 is actually released 2. Switch to using django-registration tip 3. Fork registration and include it in satchmo natively 4. Fork it and include it as a separate package Hynek has already done #4 here - https://bitbucket.org/hynekcer/django-registration/overview These options aren't necessarily mutually exclusive. We could switch to our own version then switch back later. There may be other options but I'm curious to hear what the group thinks and how they use registration today and what works and what doesn't. -Chris -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to satchmo-users@googlegroups.com. To unsubscribe from this group, send email to satchmo-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
