What might ara 2.0 look like ?

[dmsimard]

An issue to discuss this blog post (because the blog doesn't have comments enabled): https://ara.recordsansible.org/blog/2022/05/19/what-might-ara-2.0-look-like/

Thank you for reading and providing your feedback !

[dericcrago]

👋 hi @dmsimard - thanks for writing up the blog post with your thoughts. Perhaps not the feedback you're looking for, but the explanation about going from flask to django with ara 0.x to ara 1.x got me thinking... Is the next bump, going from django 3.2 to django 4.2 and dropping python < 3.8? I don't know how it will line up with the intended release schedule for ara and I'm sure you're already familiar and thinking about this, but for anyone who isn't, django 4.2 is scheduled to release in April 2023 and django 3.2 is end of extended support April 2024.

https://www.djangoproject.com/download/#supported-versions https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django

[dmsimard]

Hey @dericcrago and thanks for reaching out :)

We're bumping django from 2.2 to 3.2 with the upcoming release of ara (1.6.0) and frankly, thumbs up to the Django maintainers because the update hardly required any changes (see PR).

I'm not sure whether or not to expect the same thing for Django 4.2, there are already reports of issues when trying with django 4.x: https://github.com/ansible-community/ara/issues/393

That said, I don't think an update to django, by itself, is sufficient to warrant a major version bump. It needs to signal breaking changes and backwards incompatibility and I think we can get away with updating django without doing much of that.

When we start talking about refactoring the database model -- I talk in the blog post about JSONField which landed in django 3.2. I haven't even started to look at doing it yet but I know for sure that the changes are going to be significant enough to cause some amount of backwards incompatibility.

Perhaps everything could be made compatible but it would require a lot of work and a lot of time to an extent where it may not be sustainable for a little humble project with few contributors and that's why I would consider taking that opportunity to not carry that maintenance burden and allow ourselves to break compatibility.

Hope that makes sense.

[dericcrago]

@dmsimard - yep, that makes sense and I agree with all of that. You might even be able to get away with a database migration as part of the upgrade documentation to make changing any fields seamless as well. Django 4.2 does drop python < 3.8 though, would you put that in a major or minor release?

[dmsimard]

We will learn about how complicated database migrations will be in due time :p

To give a bit of perspective, ara 1.5.8 is the last release that will support python3.5 but that's because 1.6.0 will ship with django 3.2 which dropped support for it. I consider that it's a big enough change to warrant going from 1.5 to 1.6 but not from 1.x to 2.0.

Otherwise, Django 4.2 is still some ways out:

Judging by that timeline, I would like to think we could work through the database (and to an extent, the API) refactor and reach a 2.0 before 4.2 comes out and then maybe it would warrant a 2.1 or something.