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!
danqing
All 28 comments
Agree, would appreciate GitHub releases to match the PyPI releases at least.
mdxs
on 27 Feb 2018
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.
jaapz
on 26 Sep 2018
A tag would be very helpful
Razzeee
on 11 Oct 2018
@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!
systemcatch
on 12 Dec 2018
@systemcatch thanks, much better!
jaapz
on 13 Dec 2018
Version 0.13.0 is going to be released very soon. Quite a few changes will be coming.
systemcatch
on 21 Dec 2018
Version 0.13.0 is now available on PyPi, I'll make the tag/release on here soon.
systemcatch
on 8 Jan 2019
Awesome. Since this is already being done, I'm gonna close this issue. Thanks maintainers!
danqing
on 9 Jan 2019
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. :heavy_check_mark:
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. :heavy_check_mark:
- 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. :heavy_check_mark:
- Full ISO-8601 support.
- More to be added here......
systemcatch
on 19 Jan 2019
Now that Python 3.7 is supported I'm going to make a new 0.13.1 release shortly.
systemcatch
on 9 Feb 2019
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.
jaapz
on 11 Feb 2019
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
tois 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.
systemcatch
on 12 Feb 2019
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.
jaapz
on 15 Feb 2019
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
on 13 May 2019
Once the last few tooling update PR's are merged we'll release 0.13.3
systemcatch
on 26 May 2019
@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
on 26 May 2019
- .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.
jadchaar
on 26 May 2019
@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.
systemcatch
on 29 May 2019
@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.
jadchaar
on 30 May 2019
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?
systemcatch
on 5 Jun 2019
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鈥檚 something the tests wouldn鈥檛 catch because it only occurred for individuals that don鈥檛 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鈥檛 do considering the scope of work for arrow.
jadchaar
on 5 Jun 2019
@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
on 10 Jun 2019
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
on 31 Jul 2019
0.15.0 is now available! Please use it and give us feedback!
systemcatch
on 8 Sep 2019
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
on 17 Dec 2019
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
on 28 Jan 2020
0.15.6 has just been released, several new features and bugfixes which I'll describe in the changelog.
systemcatch
on 3 May 2020
Hey everybody, we're approaching the 1.0.0 release which is a big thing! :smile:
I think this issue has served it's purpose and can be closed now.
systemcatch
on 18 Feb 2021
Related issues
fbergero
路
4Comments
adam-rudd-myob
路
6Comments
andrewmwilson
路
7Comments
mtrahan
路
7Comments
liosha
路
7Comments
Most helpful comment
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. :heavy_check_mark:
There's some recurring issues that need to be fixed.
Ideas for dealing with get()
DST fixes
Obviously we need to fix general bugs as well.
Other ideas