Failing builds

[adrienbrunet]

There are several tox envs that fail to build.

Some of them are related to the latest version of django-filter which support django2.0 and doing so, support for older django is not guaranteed anymore.

Also, an env is impossible due to a drf37 not supporting django19. (see http://www.django-rest-framework.org/topics/3.7-announcement/#django-20-support)

Builds with latest changes on django or drf may be broken for now. But we need to wait for updates from both django, drf et django-filter. Nothing we can do on our side for now.

A PR is on its way (from me) to fix the above problems. I think we'll need to add some more docs about dependencies with django-filters and its limitation.

How long do you want to keep support for django1.8 ? It could greatly simplify our matrix support.

[adrienbrunet]

@nanuxbe Your previous changes fix all of that except the
py{27,34,35,36}-django19-drf{33,34,35,36,37}
line.
As stated, drf37 does not support django19. If it works as is, all right but it may not be worth the pain to maintain it in the future.

[nanuxbe]

Oh, I am sorry @adrienbrunet I totally missed this issue during EP2018. I figured that since you were not at the sprints I was the only one working on this :-/

tox -r -e python27-django19-drf37 fails the tests so I guess it should indeed be removed.

I've been thinking about the releases state and the support of python2 and django<1.11.
Support for drf32 has already been dropped.

There are a few more things I'd like to get done during the 0.9.x versions, mostly improve the docs (in progress) and make sure every documented feature is tested (which it currently is not) as well as fixing #43.

Once this is done, I'm thinking of releasing the 1.x branch which would support Django1.8+ and Python2.7. After the release, the branch would mostly only receive bugfixes (or small features backport if there is a need on my -or any other contributor's- side) until Django1.11 is EOL.
Django1.8 support doesn't require much work by itself compared to 1.11 but support for 1.9 and 1.10 could be dropped before the 1.x branch is reached if there is any big problem with those.

Simultaneously (almost) there would be a 2.x release branch that drops support for Python2 (same as what Django-filter did) and therefore Django<2.

What do you think?

[adrienbrunet]

Seems totally fair!
Do ask for help if you need, that's a lot of work ahead! Cheers

[nanuxbe]

It is a lot of work indeed 😛

To reach 1.0 / 2.0 here is the exhaustive list I can think of:

• As far as features and fixes, I think #43 is the most important.
• There is also some work / testing that needs to be done around all sorts of relationships, where there are a few (corner-)cases that don't always behave as expected. from the top of my head:
  • RelatedForeignKey / RelatedSlug (equivalent of foreignkey with to_field) in views with serializers that are not ModelSerializers (like used by @wizard)
  • Reverse Many2Many with no related_name
• Finish re-organizing the documentation as it stands (I started re-organizing following Danielle's method), some pages of the current documentation are blank but most of the content already exists elsewhere
• Make sure all the features are documented and even I don't think I know all the features by heart so it would be a job of looking at all the 💡 and ➕ commits to get an exhaustive list
• Make sure all the features are tested (this point is interchangeable with the point above)
• Useful or the Ember export adapter only: add a prevent_reverse property on the endpoint. This would be a list of fields (relationships) that should explicitly mention they don't have a reverse relationship (inverse: null) when the model is exported

Unrelated to the actual 1.0 and 2.0 releases, I am really bad at actually tagging releases but I'm good at creating the 🔖 commits (weird, I know). I'm pretty sure github and/or gitlab can be configured to do that for me though.

With regards to 2.0:

I guess work on that can be started on a separate branch that will be rebased on the current master as we go along. The work there looks like it might be quite straight-forward:

• Update setup.py to remove python2 / django < 2 compatibility markers
• Remove six from requirements.txt
• See what breaks and fix it
• Hunt for try / except ImportErrorand remove those (this should olso take care of obsolete DRF versions)
• Make sure we don't have any tests left for python2

If any of those appeals to you, feel free to pick any one up (even partially), just create an issue and assign it to yourself.

If you want to work on documentation and would like a "test environment", I can also give you access to our private gitlab which I like to test markdown commits on.

[adrienbrunet]

I'll try to work on it a bit in 2 weeks. About tagging etc, would you consider something like git flow to enforce the use of tags when releasing code ? It's just a suggestion, it helps me sometimes to have consistent tagging. Not sure how gitlab/GitHub could do that.

[nanuxbe]

I'm really not found of gitflow for several reasons, the main one being the fact not everything is a bug or a feature ;-)
The "emojiflow" I'm using on this project is way more complete 😛
But that's just my opinion...

I was thinking more of something along the lines of a git hook that would identify the 🔖 commits and tag the releases from there