Roadmap and ideas for arrow 🤔

[danqing]

This thread was originally opened to request GitHub release and changelogs. That has been done, and the thread is now used as roadmap and ideas. Scroll to the bottom to see them. Thanks @crsmithdev and maintainers!

[mdxs]

Agree, would appreciate GitHub releases to match the PyPI releases at least.

[jaapz]

Yep I just spent some time figuring out what's the difference between 0.12.0 and 0.12.1 because HISTORY.md was not updated to list the new (bugfix) release. Turns out it's just some dependency changes so nothing big, but it would be great if the HISTORY.md would be updated to contain this version.

[razzeee]

A tag would be very helpful

[systemcatch]

@razzeee I've made tags for versions 0.11.0, 0.12.0 and 0.12.1. Hopefully I'll get around to making releases soon.

@jaapz Plan is to update HISTORY.md with 0.12.1.

edit: We have some releases!

[jaapz]

@systemcatch thanks, much better!

[systemcatch]

Version 0.13.0 is going to be released very soon. Quite a few changes will be coming.

[systemcatch]

Version 0.13.0 is now available on PyPi, I'll make the tag/release on here soon.

[danqing]

Awesome. Since this is already being done, I'm gonna close this issue. Thanks maintainers!

[systemcatch]

I might as well use this issue to talk about future ideas & plans for arrow.

First thing I'm going to do is update the documentation as it's out of date. ✔️

There's some recurring issues that need to be fixed.

• .get() can be far too relaxed in parsing strings resulting in hard to detect errors. ✔️
• Multiple problems with how daylight savings time is dealt with.

Ideas for dealing with get()

• Simply break the API as we are below 1.0 (likely a very bad idea).
• Depreciation warning for 2-3 versions then switch.
• New keyword arg like 'strict'.
• Any other solutions welcome.

DST fixes

• Implement PEP 495 as a starter.

Obviously we need to fix general bugs as well.

Other ideas

• Change .to() to .to_timezone() since it's not a great method name. Another option could be to simply wrap it.
• Be able to load isocalender tuples into arrow. ✔️
• Full ISO-8601 support.
• More to be added here......

[systemcatch]

Now that Python 3.7 is supported I'm going to make a new 0.13.1 release shortly.

[jaapz]

Simply break the API as we are below 1.0 (likely a very bad idea).

Please don't! That will probably make a lot of people unhappy (me included).

* Depreciation warning for 2-3 versions then switch.
* New keyword arg like 'strict'.

I'd personally like the "deprecation warning" approach, maybe with a possible "loose" keyword arg so people who upgrade to the newer version can still fall back to the old behavior? I think the "strict" behaviour should be the default.

When going this route I'd also suggest very explicitly documenting which behaviours are allowed and which are considered "loose".

* Change .to() to .to_timezone() since it's not a great method name. Another option could be to simply wrap it.

I like this, because like you say to is a terribly undescriptive name.

Other than that, I personally think arrow is in a pretty good state. I wouldn't change too much.

[systemcatch]

Please don't! That will probably make a lot of people unhappy (me included).

Don't worry it's not even an option at this point.

I'd personally like the "deprecation warning" approach, maybe with a possible "loose" keyword arg so people who upgrade to the newer version can still fall back to the old behavior? I think the "strict" behaviour should be the default.

When going this route I'd also suggest very explicitly documenting which behaviours are allowed and which are considered "loose".

The first thing to do is define exactly what we're trying to prevent happening, I basically know what it is in my head but it needs to more thorough/explicit before we can find a solution.

I like this, because like you say to is a terribly undescriptive name.

How do you think we should go about implementing the change?

Other than that, I personally think arrow is in a pretty good state. I wouldn't change too much.

Yup I don't think we need to do any major revamps, just slowly make small improvements and bugfixes.

[jaapz]

How do you think we should go about implementing the change?

If it were my project I'd release one (or multiple, depending on the other issues that need to be fixed) minor version change where the to_timezone (or to_tz?) method is added, and to is clearly marked as deprecated. Then after some time I'd release a major version (probably along with some other breaking changes) that removes to and clearly documents its removal in favor of to_timezone.

Isn't that how the change from replace to shift was handled/is being handled?

Maybe others could chime in on how they think about this change.

[systemcatch]

I'll be doing some updates to the docs then releasing 0.13.2 in the next few days.

edit: 0.13.2 is out!

[systemcatch]

Once the last few tooling update PR's are merged we'll release 0.13.3

[jadchaar]

@systemcatch could we organize release goals and ideas in a GitHub Project? Having issues we want to tackle clearly laid out could entice more contributors to help out.

[jadchaar]

• .get() can be far too relaxed in parsing strings resulting in hard to detect errors.
• Multiple problems with how daylight savings time is dealt with.

Ideas for dealing with get()

• Simply break the API as we are below 1.0 (likely a very bad idea).
• Depreciation warning for 2-3 versions then switch.
• New keyword arg like 'strict'.
• Any other solutions welcome.

DST fixes

• Implement PEP 495 as a starter.

I think it is paramount that we tackle issues with get() and DST since these arrow bugs seem to be the main selling point for pendulum.

[systemcatch]

@jadchaar that's a good idea, we could use more structure. You mean like a project for each major release version (0.15.0, 0.16.0 etc etc)?

Once the last few tooling update PR's are merged we'll release 0.13.3

On reflection I think the next version should be 0.14.0 since there's some big changes incoming.

[jadchaar]

@systemcatch We could have a large project board detailing all the features we want to add (e.g. all in the backlog) and each new planned release can be a separate column. We can then pull in issues from the backlog as we see fit for a release and work on the issues.

A full kanban board would not work IMO since open source moves slowly, but I do think it is valuable to organize the ideas into a backlog and pull into a potential release column.

I agree with the 0.14.0 release since we are adding Python 3.8 support and dropping support for Python 3.4.

[systemcatch]

It's worth looking at what went wrong with the 0.14.0 and 0.14.1 releases since we don't want to make quick releases for broken installs a habit.

Can we be sure that our builds/tests would catch something like this in the future?

[jadchaar]

I agree.

That is the reason I worked to implement tox in the Travis environment. The build issue in 0.14.0 would have been caught by tox in the Travis builds since it runs the tests against a packaged version of arrow (I.e. it will go through the packaging process, thus detecting errors in setup.py).

As for the issue in 0.14.1, that’s something the tests wouldn’t catch because it only occurred for individuals that don’t use UTF-8 encoding (e.g. because they live in a different region). We just need to be cognizant going forward and remember to specify an encoding whenever we open a file for reading or writing, which we probably won’t do considering the scope of work for arrow.

[systemcatch]

@jadchaar nice ok well that's good to know.

I've setup a project board for new features in arrow at https://github.com/crsmithdev/arrow/projects/1

What I suggest we do is go through the backlog of old pull requests and close any that are stale and abandoned, but link them to the original issue for reference. Likewise let's have a final clear through the issues to try and thin them down.

For 0.15.0 the choice is either get() improvements or DST. get() produces worse bugs but DST is a big missing feature.

[systemcatch]

0.14.4 has just been released, it's essentially fixes a bug introduced in 0.14.3 and tries to correct some of the problems with backports.lru_cache that we've never been able to reproduce.

Most of the improvements on the 0.15.0 branch (https://github.com/crsmithdev/arrow/tree/Version-0.15.0) are complete and we're just writing tests + cleaning things up. Read #612 if you haven't already, arrow's parsing will become a lot more robust and strict. There is a chance this will cause some people's code to break, hence all the warnings being thrown in 0.14.3+.

We will release minor patches in 0.14.5 and maybe 0.14.6 to give further time for people to prepare. In terms of a release date date for 0.15.0 I think end of August is a realistic goal.

[systemcatch]

0.15.0 is now available! Please use it and give us feedback!

[systemcatch]

Hey everyone, we're discussing our strategy for Python 2 EOL in #739. You should check it out if you're still using 2.7.

[systemcatch]

Quick update, me and Jad have been very busy with life stuff over January hence the lack of activity on the repo.

I've been fixing some the DST bugs on another branch, but progress has been very slow.

[systemcatch]

0.15.6 has just been released, several new features and bugfixes which I'll describe in the changelog.

[systemcatch]

Hey everybody, we're approaching the 1.0.0 release which is a big thing! 😄

I think this issue has served it's purpose and can be closed now.